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

Содержание:

Введение 3
1 Анализ особенностей функционирования ETL-систем 5
1.1 Общие понятия хранилища данных 5
1.2 Общие понятия, назначение и функции ETL систем 9
1.3 Обзор существующих инструментов ETL-систем 11
1.4 Обоснование проекта по видам обеспечения 19
1.4.1 Информационное обеспечение 20
1.4.2 Программное обеспечение 29
1.4.3 Техническое обеспечение 43
1.5 Постановка задачи на проектирование 44
2 Разработка ETL-системы 46
2.1 Разработка общей архитектуры системы 46
2.2 Разработка моделей системы на языке UML 47
2.3 Разработка структурной схемы системы 54
2.4 Разработка алгоритмов работы приложения 56
3 Реализация и тестирование ETL-системы 68
3.1 Реализация программных модулей системы 68
3.2 Тестирование разработанной ETL-системы 77
Заключение 86
Список использованной литературы 89

Введение:

ВВЕДЕНИЕ
Вопросы управления данными, которым раньше уделялись вторые роли среди рассматриваемых задач, способных оказать влияние на работу предприятий, в последнее время все чаще выходят на передний план. В век цифровизации и повального использования автоматизированных систем данные становятся ценным ресурсом, и поверхностное отношение к ним не сулит ничего хорошего для устойчивой работы организаций, а тем более для их развития [5].
К сожалению, для решения вопросов управления данными на предприятии нужно преодолеть довольно много сложностей. Обусловлены они в основном историческим наследием в виде множества систем и подходов к управлению, хотя отсутствие изначальной ориентации процессов управления на качество данных тоже стоит учитывать.
Обычным явлением является ситуация, когда на предприятии существует несколько автоматизированных систем, которые внедрялись в разное время и, что очень важно, разными командами с разным мировоззрением и различными подходами к автоматизации.
Как следствие – применение разных форматов данных, разная идеология их хранения и использования, а также исторически сложившиеся процессы заведения и изменения данных. Все это приводит к тому, что данные состоят из разных наборов, которые хранятся в разных системах и заводятся с разными процедурами обеспечения качества, нацеленными на различные результаты и далеко не всегда объединенными одним устремлением.
Приведенный пример является типовым и встречается у многих компаний. Эти типовые проблемы постоянно требуют трудозатрат (ежеквартально и ежемесячно) на сведение данных для получения нужных отчетов и принятия управленческих решений. Особенно критична для сотрудников такой компании ситуация с частыми и внезапными требованиями со стороны руководства подготовить и представить определенную статистику, которая в большинстве случаев не повторяется (т. е. каждый раз нужны данные не по одному и тому же клиенту и не в одном и том же разрезе). А подобные запросы отвлекают ресурсы на сведение и подготовку данных, приостанавливая выполнение основной работы, часто на значительный промежуток времени.
Если все эти затраты суммировать, то даже за один год сумма может получиться весьма внушительной. А при отсутствии системного подхода к интеграции между приложениями разрозненные данные гарантированно превращают такие запросы руководства в трудно решаемые квесты с вечерними, а иногда и ночными посиделками персонала в попытках разобраться и свести данные в читаемую и правдивую версию. И нужно заметить, что версию правдивую удается получить не всегда. Зачастую при решении подобных задач сотрудники подгоняют данные под правдиво с их точки зрения выглядящий вариант, при этом результат может действительно оказаться правдой, а может быть и ее полной противоположностью, что, в свою очередь, приведёт к принятию неправильных решений, а затем к упущенной выгоде или даже к прямым убыткам.
Поэтому выходом из таких сложных ситуаций по управлению данными является применение систем класса ETL.
Целью магистерской диссертации является разработка программной системы, реализующей алгоритмы класса ETL.
Объектом исследования являются ETL системы.
Предметом исследования является имплементация алгоритмов работы ETL системы в программной среде.
Для достижения поставленной цели требуется решить такие задачи:
• выполнить анализ особенностей функционирования ETL-систем;
• выполнить проектирование структуры программной ETL-системы;
• выполнить реализацию и тестирование ETL-системы.
 

Текст работы:

В выпускной работе выполнено проектирование ETL-системы, которая осуществляет преобразование данных и одной СУБД в другую.
Вначале рассмотрены общие понятия хранилища данных. Хранилище данных представляет собой предметно-ориентированный, интегрированный, неизменчивый и поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений.
Представлены основные характеристики храналищ.
Традиционно хранилища имеют трехуровневую структуру.
Затем рассмотрены общие понятия ETL-систем. Раскрыты этапы работы систем такого класса.
В рамках обзора существующих инструментов рассмотрены такие системы: Talend, Pentaho, Skyvia, Informatica, Matillion. Выполнено сравнение характеристик этих систем.
Далее выполнено обоснование проекта по видам обеспечения:
• информационное обеспечение:
o тип приложения – настольное;
o модель представления данных в БД – реляционная;
o типы используемых классификаторов – локальные;
o стандарт моделирования системы – UML;
• программное обеспечение:
o язык программирования – C#;
o среда разработки – MS Visual Studio 2012;
o СУБД:
 MS SQL Server Express;
 MySQL;
 PostgreSQL.
• техническое обеспечение:
o минимальные и рекомендуемые требования к серверу;
o минимальные и рекомендуемые требования к клиенту.
Потом была составлена постановка задачи на проектирование. Обозначены цели разработки, представлены функциональные характеристики, требования к ПО и техническим средствам.
Во второй главе выполнена разработка ETL-системы.
Представлена схема общей архитектуры, где выделены общие принципы функционирования будущего приложения.
Затем для детализации понимания работы системы было выполнено построение моделей диаграмм на языке UML:
• диаграмма прецедентов;
• диаграмма классов;
• диаграмма состояний;
• диаграмма последовательностей;
• диаграмма активностей;
• диаграмма развертывания.
Эти диаграммы с разных сторон позволили взглянуть на функционал и структуру системы.
После была выполнена разработка более детализированной структурной схемы ETL-системы. Представлен список модулей.
В рамках разработки алгоритмов представлены такие блок-схемы:
• общий алгоритм работы ETL-системы;
• алгоритм подпрограммы выбора источника данных;
• алгоритм подпрограммы выбора хранилища данных;
• алгоритм подпрограммы выбора таблиц источника данных;
• алгоритм загрузки информации о таблицах;
• алгоритм подпрограммы преобразования и выгрузки данных;
• алгоритм подпрограммы проверки корректности данных в таблице;
• алгоритм подпрограммы загрузки данных;
• алгоритм подпрограммы преобразования данных в формат БД хранилища;
• алгоритм подпрограммы выгрузки таблицы в хранилище.
Третья глава посвящена непосредственной реализации и тестированию разработанной ETL-системы.
В качестве средств реализации системы использованы:
• язык программирования C#;
• среда разработки Mucrosoft Visual Studio 2012 Express;
• СУБД MS SQL SERVER Express;
• СУБД MySQL;
• СУБД PostgreSQ.
Представлено описание основных программных модулей системы и их параметров.
Тестирование показало работоспособность реализованной ETL-системы.
Спроектированная информационная система позволяет выполнять функции, присущие системам класса ETL.
Модульная структура позволит в будущем по мере необходимости наращавить фукнционал, добавляя новые СУБД или совершенствовать алгоритмы обработки данных.
Таким образом, в данной выпускной работе решены такие задачи:
• выполнен анализ особенностей функционирования ETL-систем;
• выполнено проектирование структуры программной ETL-системы;
• выполнена реализация и тестирование ETL-системы.

Заключение:

ВВЕДЕНИЕ
Вопросы управления данными, которым раньше уделялись вторые роли среди рассматриваемых задач, способных оказать влияние на работу предприятий, в последнее время все чаще выходят на передний план. В век цифровизации и повального использования автоматизированных систем данные становятся ценным ресурсом, и поверхностное отношение к ним не сулит ничего хорошего для устойчивой работы организаций, а тем более для их развития [5].
К сожалению, для решения вопросов управления данными на предприятии нужно преодолеть довольно много сложностей. Обусловлены они в основном историческим наследием в виде множества систем и подходов к управлению, хотя отсутствие изначальной ориентации процессов управления на качество данных тоже стоит учитывать.
Обычным явлением является ситуация, когда на предприятии существует несколько автоматизированных систем, которые внедрялись в разное время и, что очень важно, разными командами с разным мировоззрением и различными подходами к автоматизации.
Как следствие – применение разных форматов данных, разная идеология их хранения и использования, а также исторически сложившиеся процессы заведения и изменения данных. Все это приводит к тому, что данные состоят из разных наборов, которые хранятся в разных системах и заводятся с разными процедурами обеспечения качества, нацеленными на различные результаты и далеко не всегда объединенными одним устремлением.
Приведенный пример является типовым и встречается у многих компаний. Эти типовые проблемы постоянно требуют трудозатрат (ежеквартально и ежемесячно) на сведение данных для получения нужных отчетов и принятия управленческих решений. Особенно критична для сотрудников такой компании ситуация с частыми и внезапными требованиями со стороны руководства подготовить и представить определенную статистику, которая в большинстве случаев не повторяется (т. е. каждый раз нужны данные не по одному и тому же клиенту и не в одном и том же разрезе). А подобные запросы отвлекают ресурсы на сведение и подготовку данных, приостанавливая выполнение основной работы, часто на значительный промежуток времени.
Если все эти затраты суммировать, то даже за один год сумма может получиться весьма внушительной. А при отсутствии системного подхода к интеграции между приложениями разрозненные данные гарантированно превращают такие запросы руководства в трудно решаемые квесты с вечерними, а иногда и ночными посиделками персонала в попытках разобраться и свести данные в читаемую и правдивую версию. И нужно заметить, что версию правдивую удается получить не всегда. Зачастую при решении подобных задач сотрудники подгоняют данные под правдиво с их точки зрения выглядящий вариант, при этом результат может действительно оказаться правдой, а может быть и ее полной противоположностью, что, в свою очередь, приведёт к принятию неправильных решений, а затем к упущенной выгоде или даже к прямым убыткам.
Поэтому выходом из таких сложных ситуаций по управлению данными является применение систем класса ETL.
Целью магистерской диссертации является разработка программной системы, реализующей алгоритмы класса ETL.
Объектом исследования являются ETL системы.
Предметом исследования является имплементация алгоритмов работы ETL системы в программной среде.
Для достижения поставленной цели требуется решить такие задачи:
• выполнить анализ особенностей функционирования ETL-систем;
• выполнить проектирование структуры программной ETL-системы;
• выполнить реализацию и тестирование ETL-системы.
 

Список литературы:

1 АНАЛИЗ ОСОБЕННОСТЕЙ ФУНКЦИОНИРОВАНИЯ ETL-СИСТЕМ
1.1 Общие понятия хранилища данных
Хранилище данных представляет собой предметно-ориентированный, интегрированный, неизменчивый и поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений. Хранилища данных позволяют эффективнее, быстрее и качественнее предоставлять данные для систем их аналитической обработки, чем обычные СУБД [1] (рисунок 1.1).

Рисунок 1.1 – Возможный набор данных в хранилище
Предметная ориентированность означает, что данные в хранилище объединены в соответствии с областями, которые они описывают, а не с приложениями, которые их используют.
Интегрированность означает, что хранилище должно поддерживать совместное хранение данных различной природы, форматов и типов, отражающих различные аспекты предметной области, а не отдельные бизнес-функции. Данные содержатся внутри хранилища в его едином внутреннем формате.
Неизменчивость подразумевает что для данных в хранилище предусмотрена только операция добавления, а удалять или изменять их нельзя. Если какие-либо изменения всё же необходимы, «перегружается» все хранилище целиком. Необходимость такого подхода объясняется тем, что при промышленной эксплуатации хранилища совместно с аналитическими платформами, один и тот же запрос к нему, выполняемый в любое время, должен обеспечить предоставление одних и тех же данных. Очевидно, что если бы в хранилище были разрешены изменения, то два одинаковых запроса, выполняемые с некоторым интервалом, в течение которого данные могли измениться, сформируют два различных набора данных, анализ которых может привести к некорректным заключениям и выводам, что недопустимо.
Поддержка хронологии указывает на то, что хранение данных организована с учётом даты и времени их появления, для чего каждой записи присваивается специальная метка времени (time stamp), что позволяет извлекать данные в хронологическом порядке и анализировать временные последовательности.
Хранилища могут использовать реляционную модель, когда данные в них нормализованы, или многомерную, использующую так называемые измерения. В нормализованных хранилищах данные содержатся в таблицах третьей нормальной формы. Преимущество нормализованных ХД заключаются в простоте разработки и управления. Недостатком является необходимость денормализации данных «на лету» при их извлечении из множества таблиц при выполнении сложных аналитических запросов.
При формировании больших выборок это приводит к значительным задержкам в получении данных, а если хранилище и аналитическая платформа интегрированы в информационную систему предприятия, то возрастает нагрузка на всю систему, что может осложнить работу многих пользователей. Данную проблему частично удается решить, используя в хранилище модель данных, основанную на измерениях, которые могут используется две разновидности многомерных моделей данных – «звезда» и «снежинка». Все загружаемые в хранилище данные обязательно должны быть определены как измерение, атрибут, либо факт.
Кроме собственно данных, описывающих бизнес-процессы компании, в хранилище содержатся метаданные – служебные данные, описывающие структуру хранилища, содержащие информацию о принадлежности данных к тому или иному типу или виду (измерение, атрибут или факт). С помощью метаданных формируется семантический слой, который обеспечивает визуальные средства управления данными и метаданными. Метаданные в хранилищах разделяют на технические (обеспечивают работу самого хранилища), и бизнес-метаданные (описывают структуру данных в рамках заданной бизнес-модели).
В промышленной эксплуатации основными источниками данных для хранилищ являются OLTP-системы. Кроме этого, источниками быть любые файлы в информационной системе предприятия, в которых содержится структурированная информация, анализ которой, как ожидается, может дать полезные знания. Такие файлы могут иметь различные типы и форматы – электронных таблиц (Excel), настольных СУБД (Access), текст с разделителями (TXT, CSV-файлы), файлы учетных систем (1С:Предприятие, Парус) и т.д. Поэтому для хранилищ данных очень важно иметь развитые средства для загрузки и интегрирования данных из различных типов и форматов.
Автором концепции хранилищ данных в том виде, в каком она существует в настоящее время, считается Билл Инмон, который ввёл данный термин в 1970-х. Большой вклад в развитие теории хранилищ данных и практики их использования в области бизнес-анализа и поддержки принятия решений внес Ральф Кимбалл, который также является автором многомерной модели данных.
В настоящее время существует множество архитектур хранилища данных. Рассмотрим классическую трехуровневую архитектуру (рисунок 1.2) [2].

Рисунок 1.2 – Традиционная трехуровневая архитектура хранилища данных
Такая архитектура выделяет уровни:
• Нижний уровень: этот уровень содержит сервер базы данных, используемый для извлечения данных из множества различных источников, например, из транзакционных баз данных, используемых для интерфейсных приложений.
• Средний уровень: средний уровень содержит сервер OLAP, который преобразует данные в структуру, лучше подходящую для анализа и сложных запросов. Сервер OLAP может работать двумя способами: либо в качестве расширенной системы управления реляционными базами данных, которая отображает операции над многомерными данными в стандартные реляционные операции (Relational OLAP), либо с использованием многомерной модели OLAP, которая непосредственно реализует многомерные данные и операции.
• Верхний уровень: верхний уровень – это уровень клиента. Этот уровень содержит инструменты, используемые для высокоуровневого анализа данных, создания отчетов и анализа данных.