МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «Тверской государственный технический университет» (ТвГТУ) Кафедра информационных систем КУРСОВАЯ РАБОТА по дисциплине: Технологии обработки информации на тему: Разработка аналитической базы данных Выполнил: Левченко П.Ю. (Ф.И.О. студента) Б.ИСТ.РВС.20.35 (полное название группы) Проверил: Тверь 2023 Полтавцев А.А. СОДЕРЖАНИЕ СОДЕРЖАНИЕ ...................................................................................................... 2 ВВЕДЕНИЕ............................................................................................................. 3 1. Аналитическая часть.......................................................................................... 4 1.1 Понятие OLAP............................................................................................... 4 1.2 Архитектура OLAP-систем .......................................................................... 4 1.3 Слой извлечения, преобразования и загрузки данных ............................. 5 1.4 Слой хранения данных ................................................................................. 7 1.5 Слой анализа данных .................................................................................... 8 1.6 Структура OLAP-куба .................................................................................. 9 2. Проектная часть ............................................................................................... 11 2.1 Исходная схема OLTP БД .......................................................................... 11 2.2 Построение схемы «звезда» ....................................................................... 11 2.3 Построение и настройка многомерного куба .......................................... 18 2.4 Выгрузка в Excel ......................................................................................... 21 ЗАКЛЮЧЕНИЕ .................................................................................................... 23 СПИСОК ЛИТЕРАТУРЫ ................................................................................... 24 2 ВВЕДЕНИЕ К настоящему времени накоплены значительные объемы данных, на основе которых имеется возможность решения разнообразных аналитических и управленческих задач. В идеале работа аналитиков и руководителей различных уровней должна быть организована так, чтобы они могли иметь доступ ко всей интересующей их информации и пользоваться удобными и простыми средствами представления и работы с этой информацией. Именно на достижение этих целей и направлены информационные технологии, объединяющиеся под общим названием хранилищ данных и бизнес-анализа. В области информационных технологий всегда взаимодополняющих друг друга направления развития: существовали два • системы, ориентированные на операционную обработку данных - системы обработки данных (СОД) (OLTP); • системы, ориентированные на анализ данных - системы поддержки принятия решений (СППР) (OLAP). Непосредственно OLTP-системы не подходят для полноценного анализа информации в силу противоречивости требований, предъявляемых к OLTPсистемам и СППР. Технология OLAP (Online Analytical Processing) – технология оперативной аналитической обработки данных, использующая методы и средства для сбора, хранения и анализа многомерных данных в целях поддержки процессов принятия решений. У истоков концепции многомерного динамического анализа (OLAP), стоит основоположник реляционного подхода Э Кодд. Основное назначение OLAP-систем – поддержка аналитической деятельности, произвольных запросов пользователей – аналитиков. Цель OLAPанализа – проверка возникающих гипотез. 3 1. Аналитическая часть. 1.1 Понятие OLAP Технология OLAP (Online Analytical Processing) – технология оперативной аналитической обработки данных, использующая методы и средства для сбора, хранения и анализа многомерных данных в целях поддержки процессов принятия решений. У истоков концепции многомерного динамического анализа (OLAP), стоит основоположник реляционного подхода Э Кодд. Основное назначение OLAP-систем – поддержка аналитической деятельности, произвольных запросов пользователей – аналитиков. Цель OLAPанализа – проверка возникающих гипотез. 1.2 Архитектура OLAP-систем Полномасштабная OLAP-система должна выполнять сложные и разнообразные функции, включающие сбор данных из различных источников, их согласование, преобразование и загрузку в хранилище, хранение аналитической информации, регламентную отчетность, поддержку произвольных запросов, многомерный анализ и др. В настоящее время существуют фактические стандарты построения OLAP-систем, основанных на концепции ХД. Эти стандарты опираются на современные исследования и общемировую практику создания хранилищ данных и аналитических систем. В общем виде архитектура корпоративной OLAP-системы описывается схемой с тремя выделенными слоями: • извлечение, преобразование и загрузка данных; • хранение данных; • анализ данных. 4 Отчеты Произвольные запросы Многомерный анализ Доступ: «клиент-сервер» или web-интерфейс Витрина данных Витрина данных Data Mining Анализ данных Хранение данных Хранилище данных Извлечение, преобразование и загрузка Извлечение, преобразование и загрузка данных Источники данных Рис. 1.1. Архитектура корпоративной OLAP-системы Данные поступают из различных внутренних OLTP-систем, от подчиненных структур, от внешних организаций в соответствии с установленным регламентом, формами и макетами отчетности. Вся эта информация проверяется, согласуется, преобразуется и помещается в хранилище и витрины данных. После этого пользователи с помощью специализированных инструментальных средств получают необходимую им информацию для построения различных табличных и графических представлений, прогнозирования, моделирования и выполнения других аналитических задач. 1.3 Слой извлечения, преобразования и загрузки данных С организационной точки зрения, данный слой включает подразделения и структуры организации всех уровней, поддерживающие базы данных оперативного доступа. Он представляет собой низовой уровень генерации информации, уровень 5 внутренних и внешних информационных источников, вырабатывающих “сырую” информацию. Эта информация является рабочей для повседневной деятельности различных подразделений, которые ее вырабатывают и используют. С системно-технической точки зрения данный слой представлен ЛВС всех подразделений всех уровней, к которым подключены специализированные технические комплексы, хранящие информацию, чаще всего реализованные в виде реляционных СУБД. Из источников данных информация перемещается на основе некоторого регламента в централизованное хранилище. Как правило, необходимые для хранилища данные не хранятся в окончательном виде ни в одной из OLTP-систем. Эти данные обычно получают из исходных баз данных путем специальных преобразований, вычислений и агрегирования. Кроме того, несмотря на различную функциональную направленность, исходные транзакционные системы часто «пересекаются» по данным, т.е. их локальные базы данных содержат однотипную по смыслу информацию. Это, прежде всего, касается нормативно-справочной информации, которая используется в том или ином виде в любой OLTP-системе. При этом существенно, что одинаковые по смыслу данные обычно имеют в разных системах различный формат, вид представления, идентификацию, единицы измерения и т.п. Перед загрузкой в хранилище вся эта информация должна быть согласована, чтобы обеспечить целостность и непротиворечивость аналитических данных. Согласование данных необходимо даже при загрузке данных из одного источника. Дело в том, что в хранилище хранятся исторические данные, т.е. данные за достаточно большой промежуток времени. В оперативной системе данные хранятся в целостном виде за ограниченный промежуток, после чего они отправляются в архив. При изменениях в структуре или собственно данных архивы 6 не подвергаются никакой дополнительной обработке, а хранятся в исходном виде. Следовательно, при необходимости иметь данные за достаточно большой период времени необходимо согласовывать архивную информацию с текущей. Таким образом, загрузка данных из источников в хранилище осуществляется специальными процедурами, позволяющими: 1. извлекать данные из различных баз данных, текстовых файлов; 2. выполнять различные типы согласования и очистки данных; 3. преобразовывать данные при перемещении их от источников к хранилищу; 4. загружать согласованные и «очищенные» данные в структуры хранилища. 1.4 Слой хранения данных Слой хранения данных предназначен непосредственно для хранения значимой, проверенной, согласованной, непротиворечивой и хронологически целостной информации, которую с достаточно высокой степенью уверенности можно считать достоверной. ХД чаще всего реализуется в виде реляционной БД, работающей под управлением достаточно мощной реляционной СУБД. Такая СУБД должна поддерживать эффективную работу с терабайтными объемами информации, иметь развитые средства ограничения доступа, обеспечивать повышенный уровень надежности и безопасности, соответствовать необходимым требованиям по восстановлению и архивации. ХД не ориентировано на решение какой-либо определенной функциональной аналитической задачи. Цель ХД – обеспечить целостность и поддерживать хронологию всевозможных корпоративных данных, и с этой точки зрения оно нейтрально по отношению к приложениям. В связи с этим в большинстве случаев 7 для выполнения определенного комплекса функционально замкнутых аналитических задач рационально создавать витрины данных, в основе которых может лежать как многомерная, так и реляционная модель данных. По существу, витрина представляет собой относительно небольшое, но что самое важное, функционально-ориентированное ХД, в котором информация хранится специальным образом, оптимизированным с точки зрения решения конкретных аналитических задач некоторого подразделения или группы аналитиков. 1.5 Слой анализа данных Кроме возможности работать с единым источником информации, руководители и аналитики должны иметь удобные средства визуализации данных, агрегирования, поиска тенденций, прогнозирования. Несмотря на многообразие аналитической деятельности можно выделить типовые технологии анализа данных, каждой из которых соответствует определенный набор инструментальных средств. Вместе с хранилищем данных эти средства обеспечивают полное решение для автоматизации аналитической деятельности и создания корпоративной информационно-аналитической системы. Для организации доступа аналитиков к данным ХД и ВД используются специализированные рабочие места, поддерживающие необходимые технологии как оперативного, так и долговременного анализа. Результаты работы аналитиков оформляются в виде отчетов, графиков, рекомендаций. Аналитическая деятельность в рамках корпорации достаточно разнообразна и определяется характером решаемых задач, организационными особенностями компании, уровнем и степенью подготовленности аналитиков. В связи с этим современный подход к инструментальным средствам анализа не ограничивается использованием какой-то одной технологи. В настоящее время принято различать следующие основные вида аналитической деятельности: 8 1. стандартная отчетность; 2. нерегламентированные запросы; 3. многомерный анализ (OLAP); 4. извлечение знаний (data mining). Каждая из этих технологий имеет свои особенности, определенный набор типовых задач и должна поддерживаться специализированной инструментальной средой. 1.6 Структура OLAP-куба Возможность анализа зависимостей между различными параметрами предполагает возможность представления данных в виде многомерной модели – гиперкуба (см. рис. 1.2), или OLAP-куба. Измерение Измерение Мера Измерение Рис. 1.2. Гиперкуб Оси куба представляют собой измерения, по которым откладывают параметры, относящиеся к анализируемой предметной области, например, названия товаров и названия месяцев года. На пересечении осей измерений располагаются данные, количественно 9 характеризующие анализируемые факты – меры, например, объемы продаж, выраженные в единицах продукции. Например, в простейшем случае двумерного куба получается таблица, показывающая значения уровней продаж по товарам и месяцам. Дальнейшее усложнение модели данных возможно по нескольким направлениям: 1. увеличение числа измерений данные о продажах не только по месяцам и товарам, но и по регионам. В этом случае куб становится трехмерным; 2. усложнение содержимого ячейки нас может интересовать, например, не только уровень продаж, но и чистая прибыль или остаток на складе. В этом случае в ячейке будет несколько значений; 3. введение иерархии в пределах одного измерения – в частности общее понятие «время» связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т.д. 10 2. Проектная часть 2.1 Исходная схема OLTP БД Изначально у нас существует схема OLTP базы данных, выполненная ранее в рамках проектирования ERP проекта. Это схема БД для небольшого частного кондитерского магазина с собственной пекарней. Схема базы данных представлена на рисунке 2.1 . Рис. 2.1. Схема OLTP базы данных. 2.2 Построение схемы «звезда» Мы будем проводить анализ только продаж, без учёта расходов на списание просроченных товаров и исходных продуктов и без учёта расходов на закупку продуктов. Так же мы будем анализировать географию доставки продукции, лояльность клиентов и результативность работы сотрудников. 11 Для этого нам потребуются следующие таблицы измерений: Таблиц 1. Адреса доставки Наименование атрибута Описание id Суррогатный ключ country Страна region Область/регион region_district Областной район city Населённый пункт city_district Городской район street Улица house Номер дома building Номер корпуса litera Литера дома entrance Номер подъезда floor Номер этажа office Номер квартиры/оффиса Таблица 2. Список клиентов Наименование атрибута Описание id Суррогатный ключ name Имя клиента 12 Таблица 3. Перечень продукции Наименование атрибута Описание id Суррогатный ключ title Наименование storage_life Срок годности cost Цена Таблица 4. Список сотрудников Наименование атрибута Описание id Суррогатный ключ name Имя сотрудника position Должность сотрудника Таблица 5. Время Наименование атрибута Описание key Суррогатный ключ order_date Дата совершения заказа year Год quarter Квартал month Месяц weekday День недели 13 Так же нам необходимо построить таблицу фактов, связанную через внешние ключи с остальными таблицами. Таблица 6. Таблица фактов Наименование атрибута Описание timekey Время (внешний ключ) product Проданный продукт (внешний ключ) quantity Количество проданного продукта price Цена проданного продукта employee Сотрудник, оформивший заказ (внешний ключ) client Клиент (внешний ключ) address Адрес доставки (внешний ключ) cost Общая стоимость заказа (вычисляемый) Текст запросов на языке SQL для создания данных таблиц, настройки связей между ними и выгрузки данных из OLTP базы представлен в листинге 1. Листинг 1. USE conditerDW; GO SET ANSI_NULLS ON; GO SET QUOTED_IDENTIFIER ON; GO -- Создаём таблицу адресов доставляли) SELECT [address].* INTO [address] и забиваем 14 данными (только адреса, куда FROM conditer.dbo.[address] INNER JOIN conditer.dbo.[order] on [order].delivery = [address].id; ALTER TABLE [address] ADD CONSTRAINT PK_address PRIMARY KEY (id); -- Создаём таблицу клиентов и забиваем данными SELECT client.person AS id, person.firstname as [name] INTO client FROM conditer.dbo.client INNER JOIN conditer.dbo.person ON client.person = person.id; ALTER TABLE client ADD CONSTRAINT PK_client PRIMARY KEY (id); -- Создаём SELECT id, INTO FROM таблицу продуктов title, storage_life, cost product conditer.dbo.product; ALTER TABLE product ADD CONSTRAINT PK_product PRIMARY KEY (id); -- Создаём таблицу сотрудников и забиваем данными SELECT employee.person AS id, person.firstname as [name], employee_position.title as position INTO employee FROM conditer.dbo.employee INNER JOIN conditer.dbo.person ON employee.person = person.id INNER JOIN conditer.dbo.employee_position ON employee.position = employee_position.id; ALTER TABLE employee ADD CONSTRAINT PK_employee PRIMARY KEY (id); -- Создаём таблицу измерений времени CREATE TABLE [time] ( [key] int IDENTITY NOT NULL, [order_date] datetime NULL, [year] int NULL, [quarter] int NULL, [month] int NULL, [weekday] int NULL, CONSTRAINT PK_time PRIMARY KEY ([key]) ); GO 15 INSERT INTO [time] (order_date, [year], [quarter], [month], [weekday]) SELECT DISTINCT [date], YEAR([date]) AS [year], DATEPART(quarter, [date]) AS [month], MONTH([date]) AS [month], DATEPART(weekday, [date]) AS [weekday] FROM conditer.dbo.[order] WHERE [type] = 1 -- Только продажа ORDER BY [date]; -- Таблица фактов CREATE TABLE orders ( [timekey] int NULL, [product] int NOT NULL, [quantity] decimal(9, 3) NOT NULL, [price] money NOT NULL, [employee] int NOT NULL, [client] int NULL, [address] int NULL, [cost] AS price * quantity PERSISTED, CONSTRAINT FK_timekey FOREIGN KEY (timekey) REFERENCES ([key]), CONSTRAINT FK_product FOREIGN KEY (product) dbo.product (id), CONSTRAINT FK_employee FOREIGN KEY (employee) dbo.employee (id), CONSTRAINT FK_client FOREIGN KEY (client) REFERENCES (id), CONSTRAINT FK_address FOREIGN KEY ([address]) dbo.[address](id), dbo.[time] REFERENCES REFERENCES dbo.client REFERENCES CONSTRAINT CK_quantity CHECK(quantity >= 0), CONSTRAINT CK_price CHECK(price >= 0), ) INSERT INTO orders (timekey, product, quantity, price, employee, client, [address]) SELECT [time].[key], transact.product, transact.quantity, transact.price, [order].employee, [order].client, [order].delivery AS [address] 16 FROM conditer.dbo.[order] INNER JOIN [time] ON [order].[date] = [time].order_date INNER JOIN conditer.dbo.transact ON [order].id = transact.[order] WHERE [order].[type] = 1; Схема получившейся базы данных в топологии «звезда» представлена на рис. 2.2. Рис. 2.2. Схема ХД топологии «звезда» 17 2.3 Построение и настройка многомерного куба Используя Visual Studio построим куб из ранее полученного хранилища данных. Структура проекта, отображаемого в интерфейсе Visual Studio, представлена на рис. 2.3. Рис. 2.3. Структура проекта в Visual Studio Для удобства работы русскоязычного пользователя переименуем все атрибуты таблиц фактов и измерений на русский язык (см. рис. 2.4). 18 Рис. 2.4 Переименованные меры и измерения Настроим иерархию для таблиц адресов, времени и сотрудников (см. рис. 2.5). 19 Рис.2.5. Настроенные иерархии Для таблицы адресов так же настроим связи атрибутов (см. рис. 2.6( Рис. 2.6. Связи в таблице адресов Кроме того, для полей всех полей таблицы времени изменим тип отображаемых данных, на соответствующие названию, что позволит клиентскому приложению корректнее обрабатывать анализируемую информацию. Эту же операцию проведём с атрибутами таблиц orders и product, хранящими денежную информацию (стоимость и цену продукции). 20 2.4 Выгрузка в Excel Для непосредственной визуализации анализируемой информации отлично подходит программный комплекс Excel. Произведём выгрузку данных в виде сводной таблицы и построим сводную объёмную гистограмму. При выборе полей для анализа выберем: 1. Фильтры: • Имя сотрудника 2. Условные обозначения (столбцы): • Имя клиента • Месяц • День недели 3. Категории (строки): • Название продукции 4. Значения: • Сумма по полю Стоимость • Сумма по полю Количество • Сумма по полю Цена Результат представлен на рисунке 2.7 21 Рис. 2.8. Выгруженные данные для проведения анализа 22 ЗАКЛЮЧЕНИЕ OLAP базы данных предоставляют гибкие и мощные средства, необходимые для работы продуктовых аналитиков и руководителей предприятий. Таким образом, в процессе рассматриваемой темы я выяснил, что концепциями поддержки принятия решений может быть создана в подсистеме оперативного анализа. С целью которой и используется методика оперативной аналитической обработки данных OLAP (Online analytical processing), использующая теорию многомерного представления данных. Узнал, что множество измерений подразумевает представление данных в виде многомерной модели. Измерение – это последовательность значений одного из рассматриваемого параметра. Согласно измерениям в многомерной модели откладывают параметры, принадлежащие к рассматриваемой предметной области. По Кодду, многомерное концептуальное представление — это множественная перспектива, заключающаяся в нескольких самостоятельных измерений, вдоль которых могут быть совокупности данных. 23 проанализированы определенные СПИСОК ЛИТЕРАТУРЫ 1. Альперович М. Введение в OLAP и многомерные базы данных. – М.: Вильямс. 2012. 2. Архипенков С. Я., Голубев Д. В., Максименко О. Б. Хранилища данных. Издательство: Диалог-МИФИ, 2012. 3. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И. Методы и модели анализа данных OLAP - Издательство: БХВ-Петербург, 2013. 4. Бергер А. OLAP и многомерный анализ данных / — СПб: БХВ-Петербург, 2013. 5. Дегтярев Ю.И. Системный анализ и исследования операций. -- М.: Высш. ш., .2012. 6. Елманова Н.В., Федоров А.А. Введение в OLAP-технологии Microsoft. – М.: Диалог-МИФИ, 2014. 7. Заботнев М.С.Методы представления информации в разреженных гиперкубах данных [Электронный ресурс]. — Режим доступа: http://www.olap.ru/basic/theory.asp 8. Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных. // СУБД. – 2012. 9. Кречетов Н., Иванов П. Продукты для интеллектуального анализа данных. // ComputerWeek-Москва. – 2013. 10.Федоров А., Елманова Н. Основы OLAP // КомпьютерПресс. – 2014. 24
