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

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

Оглавление

Введение

1. Аналитический обзор

1.1 Методы анализа популярности языков программирования

1.2 Пути для организации хранилища данных

2. Проектирование

2.1 Проектирование хранилища данных

2.2 Проектирование алгоритмов загрузки данных

2.3 Разработка алгоритма анализа языковых предпочтений

3. Реализация

3.1 Организация хранилища данных

3.2 Загрузка данных и расчет агрегатов

3.3 Проведение эксперимента по анализу языковых предпочтений

Заключение

Список использованных источников

Приложения

Введение

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

Имеются статьи различных авторов [1-5], в частности педагогов, которые пытались сформулировать требования к выбору языка для обучения и рассуждали о преимуществах и недостатках языков в качестве первого для школьников и студентов. Также существуют рейтинги популярности языков среди разработчиков и работодателей. Тем не менее, имеющиеся в открытом доступе материалы представляют экспертное, но всё-таки субъективное мнение. Собственное исследование популярности языков среди студентов, обучающихся программированию, основанное на большом количестве оригинальных эмпирических данных, поможет преподавателям ВоГУ объективно оценить языковые предпочтения.

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

Объектом диссертационного исследования являются данные, накопленные в дистанционном практикуме в процессе его эксплуатации.

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

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

Задачи, поставленные в диссертационном исследовании:

· Анализ существующих подходов к исследованию популярности языков программирования

· Организация аналитического хранилища данных

· Разработка и реализация алгоритмов выгрузки данных из оперативной базы данных дистанционного практикума в хранилище данных

· Разработка алгоритма анализа языковых предпочтений

· Выгрузка данных из оперативной базы данных дистанционного практика в хранилище данных

· Расчет статистической информации, необходимой для проведения исследования

· Проведения исследования по анализу языковых предпочтений студентов и преподавателей

Методологической основой и общетеоретической базой исследования являются принципы системного анализа и проектирования баз данных.

При выполнении работы использовались основные принципы построения хранилищ данных, методы работы с базами данных, обработки данных с помощью языков SQL и PL/SQL.

Положения, выносимые на защиту:

1. Организовано аналитическое хранилище данных для базы данных дистанционного практикума по программированию.

2. Разработан и реализован алгоритм выгрузки данных из оперативной базы данных дистанционного практикума в хранилище данных.

3. Разработан и апробирован алгоритм анализа языковых предпочтений студентов и преподавателей.

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

Теоретические и практические результаты будут применены в учебном процессе кафедры АВТ.

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

Основные результаты работы докладывались и получили положительную оценку на конференциях «Современные проблемы информатики» (США, Йельм, 2016 г), «Молодые исследователи - регионам» (Вологда, 2016), «Современные тенденции развития науки и производства» (Кемерово, 2016 г). По материалам исследования были опубликованы 3 работы [6-8], из них 1 - без соавтора.

Научная квалификационная работа состоит из введения, трех глав, заключения, списка использованных источников, 12 приложений. Текст изложен на 56 страницах, содержит 7 рисунков, библиографический список использует 16 источников.



1. Аналитический обзор

1.1 Методы анализа популярности языков программирования

На сегодняшний день не существует единого мнения по поводу выбора учебного языка программирования, и часто доводы довольно субъективны. Например, преподаватель может руководствоваться лишь своими знаниями, навыками и накопленным опытом, возможно, обучать студентов тому, языку, который был первым для преподавателя в университете. При таком подходе есть риск, что выбранный язык будет «мертвым» и не актуальным на сегодняшний день.

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

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

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

На вопрос «Сколько языков программирования существует?» всемирная паутина не может дать однозначного ответа, их количество исчисляется несколькими тысячами. Как определиться с выбором в таком многообразии языков? [6]

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

Все языки можно классифицировать по нескольким признакам: новизна, принцип работы, распространенность, специализация [1].

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

Под принципом работы подразумевается является ли язык программирования компилируемым (C, Pascal) либо интерпретируемым (Perl, Python, PHP). Для процесса обучения программированию это не имеет значения, однако желательно, чтобы учащиеся четко понимали, в чем отличие в принципах работы компилируемых и интерпретируемых языков.

Распространенность характеризует насколько широко используется этот язык в настоящее время. Этот параметр играет значимую роль при выборе языка в двух аспектах: психологическом (преподавание языка, вышедшего из употребления, снизит уровень мотивации учащихся, например, языки Ada, Algol) и практический (если язык используется в настоящее время, то полученные на занятиях знания будут гораздо более востребованы, например PHP, С#, Java).

Языки делятся на императивные (процедурные), функциональные (например, Lisp), логические (например, Prolog).

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

Наиболее объективным признаком при оценке популярности языка является распространенность и применяемость языка в обучении и на практике, так как такой показатель поддается количественному подсчету и сравнительному анализу.

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

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

Что же такое хранилище данных? Хранилище представляет собой единую информационную систему хранения данных, в которой используется единая справочная информация. Зачастую оперативные БД не позволяют проводить анализ с использованием исторических данных из-за нехватки места для хранения истории или мощности, хранилище данных, в свою очередь, предоставляет такую возможность. Если оперативных систем или баз данных несколько - появляется возможность соединения и анализа информации, ранее хранившейся в разных информационных системах. Например, данные различных филиалов хранятся в разнородных системах, после внедрения ХД появляется возможность их анализа вместе, формирования единой отчетности.

Таким образом, аналитическое хранилище данных - специальным образом организованный массив данных, который обеспечивает быстрый доступ к оперативной и исторической информации, многомерный анализ данных, получение прогнозов и статистики в разрезах согласованной нормативно-справочной информации [9].

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

1. Справочники - предназначены для хранения информации об объектах предметной области;

2. Таблицы фактов - для хранения информации о фактах (происходящих событиях) предметной области;

3. Таблицы ассоциаторов - для хранения информации о наличии связей между объектами/событиями.

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

Хранилище данных для дистанционного практикума кафедры АВТ будет полезно не только как платформа для исследования популярности языков программирования, но и предоставит ряд других полезных возможностей, таких, как сохранение исторической информации, построение отчетности об успеваемости студентов, формирование статистических данных по задачам и учебным курсам, а также разгрузит оперативную базу данных, повысит производительность и удобство работы с данными, благодаря переходу на другую СУБД с FireBird на Oracle [7].

1.2 Пути для организации хранилища данных

В основе концепции хранилища данных лежат две основные идеи - интеграция разъединенных детализированных данных (детализированных в том смысле, что они описывают некоторые конкретные факты, свойства, события и т.д.) в едином хранилище и разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа. Определение понятия "хранилище данных" первым дал Уильям Г. Инмон, он определил хранилище данных как "предметно-ориентированную, интегрированную, содержащую исторические данные, не разрушаемую совокупность данных, предназначенную для поддержки принятия управленческих решений" [9,11-12].

Физическая реализация хранилища данных может быть самой разнообразной. Ниже приводятся наиболее часто встречающиеся подходы [11, 16].

Виртуальное хранилище данных - это система, представляющая интерфейсы и методы доступа к регистрирующей системе, которые эмулируют работу с данными в этой системе, как с хранилищем данных. Виртуальное хранилище данных можно организовать, создав ряд представлений (view) в базе данных, либо применив специальные средства доступа, например, продукты класса Desktop OLAP, к которым относится, например, BusinessObjects, Brio Enterprise и другие.

Главными достоинствами такого подхода являются:

*Простота и малая стоимость реализации;

*Единая платформа с источником информации;

*Отсутствие сетевых соединений между источником информации и хранилища данных.

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

· Производительности;

· Трансформации данных;

· Интеграции данных с другими источниками;

· Отсутствия истории;

· Чистоты данных;

· Зависимость от доступности основной БД;

· Зависимость от структуры основной БД.

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

· Простота и малая стоимость реализации;

· Высокая производительность за счет физического разделения регистрирующих и аналитических систем, выделения загрузки и трансформации данных в отдельный процесс, оптимизированной под анализ структурой хранения данных;

· Поддержка истории;

· Возможность добавления метаданных.

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

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



2. Проектирование

2.1 Проектирование хранилища данных

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

Хранилище данных состоит из нескольких схем, основной является схема DWH, в ней будут находиться непосредственно таблицы хранилища, куда загружаются данные из системы-источника. Для процесса загрузки также необходимы вспомогательные схемы LDR_SH, где будут находиться таблицы-шлюзы, LDR_BF для таблиц-буферов и STG - служебная схема для вычисления инкремента при загрузке. Таким образом, для каждой сущности хранилища создается четыре таблицы, по одной в каждой из описанных схем.

В первую очередь необходимо проектировать таблицы схемы DWH, таблицы вспомогательных схем строятся на основе таблицы схемы DWH.

Логическая модель схемы DWH хранилища данных представлена в приложении 2.

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

Таблицы-справочники имеют вид DET_<object> и перечислены ниже:

· DET_PROBLEM - задачи проверяющей системы;

· DET_USER - пользователи;

· DET_THEME - темы задач;

· DET_COMPILER - компиляторы, используемые при отправке решения;

· DET_RESULT - результаты;

· DET_GROUP - группы пользователей.

Справочники имеют обязательные поля:

- ID_<object> - ИД объекта в хранилище данных (ХД);

- CODE - идентификатор объекта в системе источнике (СИ), состоит из префикса системы «AVT#» и ИД из СИ;

- NAME - наименование объекта, или NAME_RU и NAME_EN - соответственно название на русском и английском языке;

- DT_OPEN - дата открытия (так как в СИ не указывается дата введения объекта/записи, то по умолчания выставляется 01.01.1900);

- DT_CHANGE - дата изменения, при первой загрузки выставляется как DT_OPEN, при появлении обновления - текущей датой;

- DT_CLOSE - дата закрытия ( в данном случае дата физического удаления из СИ);

- SYSMOMENT - Момент выгрузки данных их СИ.

Кроме обязательных имеются следующие поля:

DET_PROBLEM:

- ID_CREATOR - ИД пользователя-создателя задачи (ID_ISER из таблицы DET_USER);

- HARD_LEVEL - уровень сложности задачи;

- TIME_LIMIT - предел использования процессорного времени для данной задачи

- MEMORY_LIMIT - предел использования оперативной памяти;

- MIN_UNIQUE_PRECENT - минимальный процент уникального кода при котором решение для данной задачи считается уникальным.

DET_USER:

- USER_NAME - имя пользователя;

- SURNAME - фамилия пользователя;

- FIRST_NAME - имя пользователя;

- MIDDLE_NAME - отчество пользователя;

- LOGIN- логин пользователя;

- EMAIL - электронный адрес пользователя;

- COMMENT - дополнительная информация.

DET_COMPILER:

- LANG - язык программирования.

Таблицы-факты имеют вид FCT_<object>, в схеме только одна таблица-факт: FCT_SOLUTION - отправленные решения, которая имеет следующие поля:

- ID_SOLUTION, CODE, DT_OPEN, DT_CLOSE и SYSMOMENT - аналогично справочникам;

- ID_PROBLEM - ИД задачи (ID_ PROBLEM из таблицы DET_ PROBLEM);

- ID_USER - ИД пользователя (ID_ USER из таблицы DET_ USER);

- ID_COMPILER - ИД компилятора (ID_ COMPILER из таблицы DET_ COMPILER);

- ID_RESULT - ИД результата (ID_ RESULT из таблицы DET_ RESULT);

- FALSE_TEST_NUMBER - номер теста, на котором обнаружена ошибка, в случае неверного решения;

- TIME_WORK - максимальное (на один тест) время работы решения;

- MEMORY_USE - максимальное (на один тест) использование решением оперативной памяти;

- UNIQUE_PERCENT - процент уникальности решения;

- POINTS - количество баллов, полученные за решение;

- COMMENT - комментарий к решению.

Таблицы-ассоциаторы имеют вид ASS_<object1>_<object2>, к ним относятся:

· ASS_PROBLEME_THEME - связь тем и задач;

· ASS_DET_THEME - иерархия связей между темами;

· ASS_DET_GROUP - иерархия связей между группами пользователей;

· ASS_USER_GROUP - связь пользователей и групп пользователей.

Ассоциаторы имеют поля DT_OPEN, DT_CLOSE и SYSMOMENT аналогично справочникам и фактам, а также ИД объектов, которые в ассоциаторе связываются, например, для ASS_PROBLEME_THEME имеются ID_PROBLEM и ID_THEME, ссылающиеся на таблицы DET_PROBLEM и DET_THEME соответственно.

Таблицы-агрегаты имеют вид AGG_<name>, и имеют обязательные поля DT_OPEN, DT_CLOSE и SYSMOMENT, в которых фиксируется расчетный период и момент расчета, остальные поля являются либо внешними ключами на таблицы-справочники или факты, либо рассчитываемыми показателями.

В схеме имеется 4 таблицы-агрегата:

· AGG_LANG_YEAR_STAT - Статистика по языкам программирования за период;

· AGG_PROBLEM_STAT - Статистика по задачам за период;

· AGG_PROBLEM_RESULT_STAT - Статистика по результатам (типам результатов) и задачам за период;

· AGG_USER_STAT - Статистика по пользователям за период.

AGG_LANG_YEAR_STAT необходим для проведения исследования, а остальные агрегаты рассчитываются для проведения работ другого рода на основе хранилища данных.

Каждому агрегату соответствует процедура расчета, название которой имеет вид CALC_AGG_<name>, которая заполняет таблицу рассчитанными данными.

2.2 Проектирование алгоритмов загрузки данных

Основными процессами при формировании хранилища являются извлечение, трансформация и загрузка данных. Загрузка данных не происходит сразу в таблицы хранилища (DWH) в процессе выгрузки данные, а попадают в буферную зону (шлюз, схема LDR_SH), а уже из нее, с помощью трансформаций c использованием второй буферной зоны (схема LDR_BF), попадают в таблицы хранилища.

Рисунок 2.1 - Схема загрузки данных в хранилище

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

1. Проверка наличия записи в соответствующей таблице хранилища

Для этого результаты, выгруженные из источника, сверяются с данными в соответствующей таблице хранилища таким образом: сначала формируем поле md5 для результатов из источника и результатов из таблицы хранилища (выполняем функцию md5 по всем не ключевым полям, но значимым полям), далее производим соединение результатов Full Outer Join по ключевым полям, после этого имеется несколько вариантов развития событий:

· Существует ключевые поля (коды) в источнике, в хранилище - null: такую запись необходимо вставить в хранилище (INSERT)

· Существует ключевые поля (коды) в хранилище, в источнике - null: такую запись необходимо удалить из хранилища (или закрыть) (DELETE)

· Существует ключевые поля (коды) в хранилище и в источнике, поля md5 различны: такую запись необходимо обновить в хранилище (UPDATE)

· Существует ключевые поля (коды) в хранилище и в источнике, поля md5одинаковы: такая запись отбрасывается (REJECT)

2. Создание дополнительной схемы STG для выявления инкремента и сверка с ней

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

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

· DT - дата DML-операции (вставка/изменение/удаление данных) по объекту в учетной системе

· REC_STATUS - вид DML-операции, произведенной над записью в учетной системе. Значения атрибута:

· 0 - добавление нового или изменение существующего объекта;

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

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

После выбора инкремента из СИ происходит загрузка данных в шлюз (LDR_SH). Независимо от типа данных в хранилище, все поля в таблице-шлюзе должны быть текстовыми. Формат данных в источнике отличается от внутреннего формата хранилища, в первую очередь, тем, что в источнике объекты идентифицируются через коды, сформированные на основе идентификаторов учетной системы. Будем называть такие коды внешними идентификаторами. Например, если объект в учетной системе «System1» имеет уникальный код «1234» в рамках данной системы, то внешний идентификатор будет выглядеть следующим образом: «System1#1234». Каждому внешнему идентификатору соответствует альтернативный ключ в таблице хранилища (CODE).

В хранилище все объекты идентифицируются через внутренние идентификаторы. Для каждого объекта, кроме внутреннего идентификатора, хранится его внешний идентификатор, чтобы всегда можно было однозначно определить соответствующий объект учетной системы. Например, для рассмотренного выше объекта с кодом «System1#1234» внутренний идентификатор (ID_OBJECT) может выглядеть как 123456789. Внутренние идентификаторы формируются в ходе загрузки данных в хранилище.

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

2.3 Разработка алгоритма анализа языковых предпочтений

Для проведения исследования необходимо, в первую очередь, рассчитать статистические показатели по применению языков программирования по годам за период 2005-2016 гг. Для расчета необходимо создать процедуру и поместить данные в таблицу AGG_LANG_YEAR_STAT.

Фактом применения языка программирования является первое отправленное на проверку решение конкретным пользователем конкретной задачи в дистанционном практикуме.

Рассчитываемые показатели:

1. Общее количество фактов применения языка за конкретный год

2. Количество фактов применения языка студентами за конкретный год

3. Количество фактов применения языка участниками олимпиад за конкретный год

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

3. Реализация

3.1 Организация хранилища данных

В соответствии со спроектированной моделью хранилища данных (схемы DWH) был реализован скрипт на создание хранилища данных.

В первую очередь необходимо создать схемы базы данных, для этого создаются соответствующие пользователь в базе данных:

CREATE USER DWH IDENTIFIED BY DWH;

CREATE USER STG IDENTIFIED BY STG;

CREATE USER LDR_SH IDENTIFIED BY LDR_SH;

CREATE USER LDR_BF IDENTIFIED BY LDR_BF;

Далее необходимо создать последовательности, для формирования ИД объектов хранилища:

CREATE SEQUENCE dwh.objseq

MINVALUE 1

MAXVALUE 9999999999999999

START WITH 1

INCREMENT BY 1;

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

CREATE TABLE dwh.load_status

(table_name varchar2(30), --Название таблицы

sysmoment date); --Дата загрузки

Затем создаются таблицы хранилища в соответствии с построенной логической моделью (Приложение 2) и вспомогательные таблицы. Пример скрипта на создание таблицы-справочника представлен в Приложении 3, создание таблицы-ассоциатора описано в Приложении 4, скрипт на создание таблицы-факта - в Приложении 5.

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

3.2 Загрузка данных и расчет агрегатов

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

После загрузки запускаются расчеты агрегатов
за период, указанный в параметрах (date_from, date_to), или без параметров - на всем загруженном объеме данных.

begin

dwh.calc_agg_problem_stat();

dwh.calc_agg_problem_result_stat();

dwh.calc_agg_user_stat();

dwh.calc_agg_lang_year_stat();

end;

Данных из базы данных дистанционного практикума по программированию кафедры АВТ загружены в хранилище данных по состоянию на 4 июня 2017 года, агрегаты по задачам и пользователям рассчитаны за весь выгруженный период с 17.04.2004 по 04.06.2017, статистика по задачам посчитана за полные 2005-2016 года.



3.3 Проведение эксперимента по анализу языковых предпочтений

Рассчитанные результаты по количеству применений языков программирования в решениях представлены в Приложениях 10-11, графически эти результаты отражены в рисунках 3.1, 3.3 и 3.5.

На рисунке 3.1 представлен график изменения количества применений языков программирования во всех решениях по годам.

Рисунок 3.1 - График изменения количества применений языков программирования во всех решениях

Проанализировав представленный график, были выделены 4 языка, с наибольшими показателями применения, а, следовательно, пользующиеся большей популярностью. На рисунке 3.2 отражены доли количества применения лидирующих языков от общего количества решений. Исходя из представленных графиков, можно сделать вывод, что наиболее популярными языками программирования среди пользователей дистанционного практикума по программирования кафедры АВТ за период 2005-2016 годов являются языки SQL, C++, Java и Pascal.

Также на рисунке 3.2 можно отследить тенденцию изменения популярности этих языков.

Рисунок 3.2 - Доли количества применения языков от общего количества решений

Язык программирования Pascal занимал первую строчку по популярности среди немногочисленных языков в 2005 году, но с течением времени теряет свою популярность среди пользователей дистанционного практикума.

Язык SQL, появившись в дистанционном практикуме в 2007 году, занимает лидирующую позицию среди всех языков, доступных в практикуме, с появления и до конца исследуемого периода.

Язык программирования С++ в основном является вторым по популярности среди пользователей, редко занимая лидирующую позицию.

Язык Java, как видно по рисунку 3.2, стал доступен для проверки решений в 2007 году, и с того времени с переменным успехом набирает популярность.

На рисунке 3.3 представлен график изменения количества применений языков программирования в решениях студентов по годам.

Рисунок 3.3 - График изменения количества применений языков программирования в решениях студентов

После анализа рисунка 3.3 были выделены 4 языка, с наибольшими показателями применения, а, следовательно, пользующиеся большей популярностью среди студентов. На рисунке 3.4 отражены доли количества применения лидирующих языков от общего количества решений студентами. Исходя из представленных графиков, можно сделать вывод, что наиболее популярными языками программирования среди пользователей дистанционного практикума по программирования кафедры АВТ за период 2005-2016 годов являются языки SQL, C++, Java и Pascal.

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

Язык программирования С++ пользуется большой популярностью среди студентов в исследуемый период. С появлением языка SQL, С++ стал отходить на второй план по количеству применений. Эти 2 языка, SQL и C++, можно назвать равными лидерами в исследовании решений студентов за 2005-2016 года.

Язык программирования Pascal имеет меньшую популярность в сравнении с описанными выше лидирующими языками, но занимает третью, редко вторую, строчку в рейтинге популярности.

Популярность языка Java с появления 2007 года имела спад в 2001--2013 годах, но с 2014 стала возрастать. Тем не менее, в исследуемый период язык не является самым популярным.

Рисунок 3.4 - Доли количества применения языков от общего количества решений студентами

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

Рисунок 3.5 - График изменения количества применений языков программирования в решениях участников олимпиад

Рисунок 3.6 - Доли количества применения языков от общего количества решений участниками олимпиад

Во всех трех группах исследованных решений были выделены 4 язык: SQL, C++, Java и Pascal. Язык программирования Pascal, хоть и попал в этот список, имеет тенденцию к «увяданию» и потере популярности среди пользователей дистанционного практикума. Остальные языки имеют либо положительную тенденцию изменения популярности с незначительными спадами.



Заключение

В ходе выполнения работы был решены следующие задачи:

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

· Организовано аналитического хранилища данных;

· Разработаны и реализованы алгоритмы выгрузки данных из оперативной базы данных дистанционного практикума в хранилище данных;

· Разработан алгоритма анализа языковых предпочтений;

· Загружены данных из оперативной базы данных дистанционного практикума в хранилище данных;

· Рассчитаны статистические показатели, необходимые для проведения исследования и работы с хранилищем данных.

· Проведено исследование по анализу языковых предпочтений студентов и преподавателей.

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

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

Список использованных источников

1. Выбор языка для обучения программированию // Конгесс конференций [Электронный ресурс] Режим доступа: http://ito.su/main.php?pid=26&fid=7732

2. Годочкин Е. Ю. Проблемы преподавания информатики и информационных технологий экономическим специальностям в ВУЗах // Молодой ученый. -- 2011. -- №11. Т.1. -- С. 67-69.

3. Бобров А. Н. Проблемы выбора языка программирования в школьном курсе информатики // Молодой ученый. -- 2015. -- №24. -- С. 61-64.

4. Какой язык программирования стоит выучить первым? //Хабрахабр [Электронный ресурс] Режим доступа: https://habrahabr.ru/company/ruvds/blog/315572/

5. Десять мнений: какой язык программирования учить первым // Записки программиста [Электронный ресурс] Режим доступа: http://eax.me/first-programming-language/

6. Голубева А.С., Проблема выбора языковых средств для обучения программированию студентов профильных направлений подготовки / Голубева А.С., Ржеуцкая С.Ю. // Молодые исследователи - регионам: материалы международной научной конференции. В 3-х т. / Мин-во обр. и науки РФ ; Вологод. гос. ун-т. - Вологда : ВоГУ, 2016. - Т. 1. -c. 58-60.

7. Голубева А.С., Анализ языковых предпочтений студентов на основе хранилища данных дистанционного практикума по программированию / Голубева А.С. // Современные тенденции развития науки и производства: сборник материалов IV Международной научно-практической конференции - Кемерово: ЗапСибНЦ, 2016 - Т. 2. -c. 125-126

8. Golubeva A.S. The usage of multilingual approach in learning the basics of algoritmization and programming / Golubeva A.S., Basalaeva Yu.S. // Modern informatization problems in simulation and social technologies: Proceedings of the XX-th International Open Science Conference (Yelm,WA, USA, January 2016) - Yelm: Science Book Publishing House, 2016. - P. 219-223.

9. Что такое корпоративное хранилище данных (Data Warehouse) и кому его продавать [Электронный ресурс] Режим доступа:
http://www.prj-exp.ru/dwh/what_is_dwh.php

10. Спирли Э. Корпоративные хранилища данных. Планирование, разработка, реализация. Том. 1: Пер. с англ. - М.: Издательский дом "Вильямс", 2001.

11. Хранилища данных: основные архитектуры и принципы построения в реляционных СУБД // BI Partner [Электронный ресурс] Режим доступа: http://www.bipartner.ru/resources/dw_arch.html

12. Inmon W.H. Building the Data Warehouse, 4th Edition. -- Hoboken, NJ:Wiley, 2005. -- 576 p.

13. Федоров А. Введение в OLAP. ч.2. Хранилища данных / Федоров А., Елманова Н. // Компьютер Пресс. - 2001. - № 5.

14. Kimball R. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, second edition / Kimball R., Ross M. -- Wiley, 2002. -- 421 с.

15. Silberschatz A. Database System Concepts: 5th Edition /A. Silberschatz, Henry F. Korth, S. Sudarshan. -- McGraw-Hill, August 9, 2005. [Электронный ресурс] -- Режим доступа: http://codex.cs.yale.edu/avi/db-book/db5/slide-dir/ch9.ppt

16. Асадуллаев С. Архитектуры хранилищ данных -- 1. -- 2009. [Электронный ресурс] -- Режим доступа: http://www.ibm.com/developerworks /ru/library/sabir/axd_1/

Приложения

Приложение 1

Логическая модель базы данных дистанционного практикума кафедры АВТ

Приложение 2

Логическая модель хранилища данных (схема DWH)

Приложение 3

Листинг скрипта создания таблицы-справочника

CREATE TABLE dwh.det_problem (

id_problem NUMBER(16) NOT NULL,

code VARCHAR2(100) NOT NULL,

name_ru VARCHAR2(250),

name_en VARCHAR2(250),

id_creator NUMBER(16),

hard_level NUMBER(16),

time_limit NUMBER(32,5),

memory_limit NUMBER(16),

min_unique_percent NUMBER(16),

dt_open DATE NOT NULL,

dt_change DATE NOT NULL,

dt_close DATE NOT NULL,

sysmoment DATE NOT NULL

);

ALTER TABLE dwh.det_problem ADD CONSTRAINT det_problem_pk PRIMARY KEY ( id_problem );

ALTER TABLE dwh.det_problem ADD CONSTRAINT det_problem_ak UNIQUE ( code );

ALTER TABLE dwh.det_problem ADD CONSTRAINT det_problem_det_user_fk FOREIGN KEY ( id_creator )

REFERENCES dwh.det_user ( id_user )

ON DELETE CASCADE;

CREATE TABLE stg.det_problem (

code VARCHAR2(100) NOT NULL,

md5 VARCHAR2(50)

);

ALTER TABLE stg.det_problem ADD CONSTRAINT stg_det_problem_ak UNIQUE ( code );

CREATE TABLE ldr_sh.det_problem (

code VARCHAR2(100),

name_ru VARCHAR2(250),

name_en VARCHAR2(250),

creator_code VARCHAR2(100),

hard_level VARCHAR2(16),

time_limit VARCHAR2(32),

memory_limit VARCHAR2(16),

min_unique_percent VARCHAR2(16),

dt VARCHAR2(10),

rec_status VARCHAR2(2),

sysmoment VARCHAR2(20)

);

CREATE TABLE ldr_bf.det_problem (

id_problem NUMBER(16),

code VARCHAR2(100),

name_ru VARCHAR2(250),

name_en VARCHAR2(250),

id_creator NUMBER(16),

hard_level NUMBER(16),

time_limit NUMBER(32,5),

memory_limit NUMBER(16),

min_unique_percent NUMBER(16),

creator_code VARCHAR2(100),

dt_open DATE,

dt_close DATE,

rec_status number(1),

sysmoment DATE

);



Приложение 4

Листинг скрипта создания таблицы-ассоциатора

CREATE TABLE dwh.ass_user_group (

id_user NUMBER(16) NOT NULL,

id_group NUMBER(16) NOT NULL,

dt_open DATE NOT NULL,

dt_close DATE NOT NULL,

sysmoment DATE NOT NULL

);

ALTER TABLE dwh.ass_user_group ADD CONSTRAINT ass_user_group_ak UNIQUE ( id_user,id_group );

ALTER TABLE dwh.ass_user_group ADD CONSTRAINT ass_user_group_det_group_fk FOREIGN KEY ( id_group )

REFERENCES dwh.det_group ( id_group )

ON DELETE CASCADE;

ALTER TABLE dwh.ass_user_group ADD CONSTRAINT ass_user_group_det_user_fk FOREIGN KEY ( id_user )

REFERENCES dwh.det_user ( id_user )

ON DELETE CASCADE;

CREATE TABLE stg.ass_user_group (

user_code VARCHAR2(100),

group_code VARCHAR2(100)

);

ALTER TABLE stg.ass_user_group ADD CONSTRAINT stg_ass_user_group_ak UNIQUE ( user_code,group_code );

CREATE TABLE ldr_sh.ass_user_group (

user_code VARCHAR2(100),

group_code VARCHAR2(100),

dt VARCHAR2(10),

rec_status VARCHAR2(2),

sysmoment VARCHAR2(20)

);

CREATE TABLE ldr_bf.ass_user_group (

id_user NUMBER(16),

id_group NUMBER(16),

user_code VARCHAR2(100),

group_code VARCHAR2(100),

dt_open DATE,

dt_close DATE,

rec_status number(1),

sysmoment DATE

);



Приложение 5

Листинг скрипта создания таблицы-факта

CREATE TABLE dwh.fct_solution (

id_solution NUMBER(16) NOT NULL,

id_problem NUMBER(16) NOT NULL,

id_user NUMBER(16) NOT NULL,

id_compiler NUMBER(16) NOT NULL,

id_result NUMBER(16) NOT NULL,

code VARCHAR2(100) NOT NULL,

false_test_number NUMBER(16),

time_work NUMBER(32,9),

memory_use NUMBER(32),

unique_precent NUMBER(32,5),

points NUMBER(16),

commentary VARCHAR2(250),

dt_open DATE NOT NULL,

dt_close DATE NOT NULL,

sysmoment DATE NOT NULL

);

ALTER TABLE dwh.fct_solution ADD CONSTRAINT fct_solution_pk PRIMARY KEY ( id_solution );

ALTER TABLE dwh.fct_solution ADD CONSTRAINT fct_solution_ak UNIQUE ( code );

ALTER TABLE dwh.fct_solution ADD CONSTRAINT fct_solution_det_compiler_fk FOREIGN KEY ( id_compiler )

REFERENCES dwh.det_compiler ( id_compiler )

ON DELETE CASCADE;

ALTER TABLE dwh.fct_solution ADD CONSTRAINT fct_solution_det_problem_fk FOREIGN KEY ( id_problem )

REFERENCES dwh.det_problem ( id_problem )

ON DELETE CASCADE;

ALTER TABLE dwh.fct_solution ADD CONSTRAINT fct_solution_det_result_fk FOREIGN KEY ( id_result )

REFERENCES dwh.det_result ( id_result )

ON DELETE CASCADE;

ALTER TABLE dwh.fct_solution ADD CONSTRAINT fct_solution_det_user_fk FOREIGN KEY ( id_user )

REFERENCES dwh.det_user ( id_user )

ON DELETE CASCADE;

CREATE TABLE stg.fct_solution (

code VARCHAR2(100) NOT NULL,

md5 VARCHAR2(50)

);

ALTER TABLE stg.fct_solution ADD CONSTRAINT stg_fct_solution_ak UNIQUE ( code );

CREATE TABLE ldr_sh.fct_solution (

code VARCHAR2(100),

problem_code VARCHAR2(100),

user_code VARCHAR2(100),

compiler_code VARCHAR2(100),

result_code VARCHAR2(100),

false_test_number VARCHAR2(16),

time_work VARCHAR2(33),

memory_use VARCHAR2(32),

unique_precent VARCHAR2(33),

points VARCHAR2(16),

commentary VARCHAR2(250),

dt VARCHAR2(10),

rec_status VARCHAR2(2),

sysmoment VARCHAR2(20)

);

CREATE TABLE ldr_bf.fct_solution (

id_solution NUMBER(16),

id_problem NUMBER(16),

id_user NUMBER(16),

id_compiler NUMBER(16),

id_result NUMBER(16),

code VARCHAR2(100),

false_test_number NUMBER(16),

time_work NUMBER(32,9),

memory_use NUMBER(32),

unique_precent NUMBER(32,5),

points NUMBER(16),

commentary VARCHAR2(250),

problem_code VARCHAR2(100),

user_code VARCHAR2(100),

compiler_code VARCHAR2(100),

result_code VARCHAR2(100),

dt_open DATE,

dt_close DATE,

rec_status number(1),

sysmoment DATE

);



Приложение 6

Листинг скрипта по созданию процедуры для расчета агрегата «Статистика по языкам программирования за период»

create or replace procedure dwh.calc_agg_lang_year_stat(

p_date_from in date default null,

p_date_to in date default null)

is

l_date_from date;

l_date_to date;

begin

if p_date_from is null

then select min(dt_open) into l_date_from from dwh.fct_solution;

else l_date_from := p_date_from;

end if;

if p_date_to is null

then select max(dt_open) into l_date_to from dwh.fct_solution;

else l_date_to := p_date_to;

end if;

--чистим, если на этот период статистика уже подсчитывалась

delete from dwh.agg_lang_year_stat where dt_open = l_date_from

and dt_close = l_date_to;

commit;

-- Сбор статистики по языкам за период

insert into dwh.agg_lang_year_stat

select

extract(year from s.dt_open) as year, --Год

c.lang, --Язык программирования

count(1) as cnt, -- Общее количество решений

nvl(max(st.cnt), 0) as st_cnt, --Количество решений студентов

nvl(max(ol.cnt), 0) as ol_cnt, --Количество решений олимпиадников

l_date_from as dt_open, --Дата начала периода расчета

l_date_to as dt_close, --Дата окончания периода расчета

sysdate as sysmoment --Дата расчета

from (select min(s.dt_open) as dt_open, id_compiler from dwh.fct_solution s

group by id_problem, id_compiler, id_user) s

join dwh.det_compiler c on s.id_compiler = c.id_compiler

left join (select extract(year from s.dt_open) as year, c.lang,

count(1) as cnt

from (select max(s.dt_open) as dt_open, id_compiler, id_user

from dwh.fct_solution s

group by id_problem, id_compiler, id_user) s

join dwh.det_compiler c on s.id_compiler = c.id_compiler

join dwh.ass_user_group aug on s.id_user = aug.id_user

join dwh.det_group g on aug.id_group = g.id_group

and g.code ='AVT#3' --Студенты

where s.dt_open between l_date_from and l_date_to

group by c.lang, extract(year from s.dt_open)) st

on extract(year from s.dt_open) = st.year and c.lang = st.lang

left join (select extract(year from s.dt_open) as year, c.lang,

count(1) as cnt

from (select max(s.dt_open) as dt_open, id_compiler, id_user

from dwh.fct_solution s

group by id_problem, id_compiler, id_user) s

join dwh.det_compiler c on s.id_compiler = c.id_compiler

join dwh.ass_user_group aug on s.id_user = aug.id_user

join dwh.det_group g on aug.id_group = g.id_group

and g.code ='AVT#4' --Олимпиадники

where s.dt_open between l_date_from and l_date_to

group by c.lang, extract(year from s.dt_open)) ol

on extract(year from s.dt_open) = ol.year and c.lang = ol.lang

where s.dt_open between l_date_from and l_date_to

group by c.lang, extract(year from s.dt_open);

commit;

end;



Приложение 7

Листинг скрипта загрузки данных в таблицу-справочник

------- ШАГ ЗАГРУЗКУ В ШЛЮЗ -------

-- создаем промежуточную таблицу для регистрации изменений в STG

create table stg.temp_table as

select

case

when src.code is not null and stg.code is null then 'DD_INSERT'

when src.code is not null and stg.code is not null and src.md5 <> stg.md5 then 'DD_UPDATE'

when src.code is null and stg.code is not null then 'DD_DELETE'

else 'DD_REJECT' end as action,

nvl(src.code, stg.code) as code,

src.md5 as md5 ,

src.CREATOR_CODE as CREATOR_CODE,

src.NAME_RU as NAME_RU,

src.NAME_EN as NAME_EN,

src.HARD_LEVEL as HARD_LEVEL,

src.TIME_LIMIT as TIME_LIMIT,

src.MEMORY_LIMIT as MEMORY_LIMIT,

src.min_unique_percent as min_unique_percent,

dt as DT,

to_char(sysdate, 'yyyymmdd') as sysmoment

from (

select

'AVT#'||p.id_prb as CODE,

decode(p.id_creator, null, null, 'AVT#'||p.id_creator) as CREATOR_CODE,

pl.name as NAME_RU,

pl_en.name as NAME_EN,

p.hardlevel as HARD_LEVEL,

p.time_lim as TIME_LIMIT,

p.mem_lim as MEMORY_LIMIT,

p.min_uniq_proc as min_unique_percent,

'19000101' as DT,

substr(ora_hash(pl.name||pl_en.name||p.hardlevel||p.time_lim|| p.mem_lim||p.min_uniq_proc||p.id_creator), 1, 50) as md5

from problems@acmlink p

left join problems_lng@acmlink pl on p.id_prb = pl.id_prb and pl.id_lng = 'ru'

left join problems_lng@acmlink pl_en on p.id_prb = pl_en .id_prb and pl_en .id_lng = 'en') src

full join stg.det_problem stg on src.code = stg.code;

--вставляем данные в шлюз

insert into ldr_sh.det_problem (code, creator_code, name_ru, name_en, hard_level, time_limit, memory_limit, min_unique_percent, dt, rec_status, sysmoment)

select

code,

creator_code,

name_ru,

name_en,

hard_level,

time_limit,

memory_limit,

min_unique_percent,

dt,

decode(action , 'DD_DELETE', '1', '0') as rec_status,

sysmoment

from stg.temp_table s

where action <> 'DD_REJECT';

-- регистрируем изменения в STG

insert into stg.det_problem (code, md5)

select code, md5 from stg.temp_table where action = 'DD_INSERT';

merge into stg.det_problem stg

using (select * from stg.temp_table where action = 'DD_UPDATE') t

on (stg.code = t.code)

when matched

then update set stg.md5 = t.md5;

delete from stg.det_problem where code in (select code from stg.temp_table where action = 'DD_DELETE');

-- удаляем промежуточную таблицу

drop table stg.temp_table;

------- ШАГ ТРАНСФОРМАЦИИ -------

insert into ldr_bf.det_problem (id_problem, id_creator, code, creator_code, name_ru, name_en, hard_level, time_limit, memory_limit, min_unique_percent, dt_open, dt_close, rec_status, sysmoment)

select

(select id_problem from dwh.det_problem dwh where dwh.code = sh.code) as id_problem ,

(select id_user from dwh.det_user dwh where dwh.code = sh.creator_code) as id_creator,

sh.*

from (

select

substr(code, 1, 100) as code,

substr(creator_code, 1, 100) as creator_code,

substr(name_ru, 1, 250) as name_ru,

substr(name_en, 1, 250) as name_en,

to_number(hard_level) as hard_level,

to_number(time_limit) as time_limit,

to_number(memory_limit) as memory_limit,

to_number(min_unique_percent) as min_unique_percent,

to_date(dt, 'yyyymmdd') as dt_open,

to_date('30010101', 'yyyymmdd') as dt_close,

to_number(rec_status) as rec_status,

to_date(sysmoment, 'yyyymmdd') as sysmoment

from ldr_sh.det_problem) sh;

commit;

-- чистим шлюз