Создание базы (хранилища) данных для сети супермаркетов

Контрольная работа На тему: «Создание базы (хранилища) данных для сети супермаркетов»

Выполнил: Рогалин Михаил Юрьевич Руководитель: Акопов Андраник Сумбатович Оглавление

• Введение
• Разработка схемы хранилища данных
• Описания схем отношений хранилища данных
• Разработка OLAP-куба
• Разработка запросов
• Запрос № 1
• Запрос № 2
• Запрос № 3
• Запрос № 4
• Запрос № 5
• Заключение
• Список литературы

Постановка задачи. Требуется создать специально разработанное хранилище данных супермаркета, которое предназначенное для подготовки отчётов и бизнес-анализа с целью поддержки принятия решения в организации. Строится на базе систем управления базами данных и систем поддержки принятия решения. Используя «SQL Server Management Studio» и «SQL Server Business Intelligence Development», необходимо создать базу данных и в дальнейшем построить куб на основе созданной базы. Из-за большого массива данных актуальнее использовать OLAP-структуру, созданная из рабочих данных, называемой OLAP-куб. Куб создаётся из соединения таблиц с применением схемы звезды. В центре схемы звезды находиться таблица фактов, которая содержит ключевые факты, по которым делаются запросы. Я считаю, что схема «звезда» точнее всего отразит структуру супермаркета, так как удобна для хранения многомерных показателей.

Передо мной были поставлены следующие задачи:

Построить модель функционирования рассматриваемой предметной области;

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

Создание OLAP-куба для дальнейшего анализа информации;

Разработка запросов, позволяющих оценить эффективность работы торгового предприятия;

Разработка схемы хранилища данных

Первым этапом при разработке хранилища данных было изучение предметной области «Информационно-аналитическая система супермаркета». Далее при разработке модели хранилища данных были выделены следующие таблицы:

Таблицы измерений:

· Время

· Поставщик

· Продавцы

· Товар Таблица фактов:

· Продажа товара На рисунке 1 представлена физическая модель разработанного хранилища данных.

Рисунок 1

идентифицирующая связь

идентифицирующая связь

связь «многие ко многим»

неидентифицируемая связь Рассмотрим подробное описание таблиц разработанного хранилища данных:

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

хранилище запрос товар супермаркет

Описания схем отношений хранилища данных

· Связь «Товар» и «Продажа товара»

Существует для отображения подробной информации о товаре. Выступает как идентифицирующая связь, определенная отношением «Один ко многим». Сущность «Товар» является родительской, а «Продажа товара» — дочерней. Мощность данного отношения на диаграмме обозначена маркером P («один или более»).

· Связь «Время» и «Продажа товара»

Существует для отображения подробной информации о времени. Выступает как идентифицирующая связь, определенная отношением «Один ко многим». Сущность «Время» является родительской, а «Продажа товара» — дочерней. Мощность данного отношения на диаграмме обозначена маркером P («один или более»).

· Связь «Продавцы» и «Продажа товара»

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

Выступает как идентифицирующая связь, определенная отношением «Один ко многим». Сущность «Продавцы» является родительской, а «Продажа товара» — дочерней. Мощность данного отношения на диаграмме обозначена маркером P («один или более»).

· Связь «Поставщик» и «Продажа товара»

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

Выступает как идентифицирующая связь, определенная отношением «Один ко многим». Сущность «Поставщик» является родительской, а «Продажа товара» — дочерней. Мощность данного отношения на диаграмме обозначена маркером P («один или более»).

Разработка OLAP-куба

После создания и заполнения таблиц в «SQL Server Management Studio» можно приступить к построению куба в «SQL Server Business Intelligence Development», измерениями которого будут таблицы: Товар, Время, Продавцы, Поставщик, Продажа товара (рис. 2).

Создадим измерение на основе таблицы «Товар» (рис.3):

Рисунок 3

Создадим измерение и иерархию на основе таблицы «Время» (рис.4):

Рисунок 4

Создадим измерение и иерархию на основе таблицы «Продавцы» (рис.5):

Рисунок 5

Создадим измерение и иерархию на основе таблицы «Поставщик» (рис.6):

Рисунок 6

Создание куба (рис 7):

Разработка запросов

Для разработки отчета был выполнен следующий MDX-запрос к OLAP-кубу:

Запрос № 1

Данный запрос позволяет узнать количество проданного товара продавцом по имени «Амур». ([Продавцы]. Имя]. Амур]) — это кортеж, который ссылается на ячейки, соответствующие продавцу «Амур». Результат запроса таков, что количество проданного товара продавцом «Амур» составляет 8 штук.

Запрос № 2

Данные запрос более широко даёт информацию о количестве проданного товара по единицам определённым продавцом. Так «Амур» продал всего 8 товаром из которых, 2 — кабеля и 6 — твиксов.

Два столбца, выбираемых запросом SQL, теперь представлены по осям COLUMNS и ROWS. Условие в предложении WHERE SQL запроса (которое представляет собой выражение, сравнивающее строковые значения) теперь преобразовано в предложение WHERE MDX. Несмотря на то, что запросы SQL и MDX выглядят похоже, операции, выполняемые в «SQL Server» и «Analysis Services», заметно отличаются.

Запрос № 3

Запрос № 3 позволяет узнать, сколько продал определённый продавец? С помощью именного набора выяснилось всего «Амур» продал 2380 штук.

MDX позволяет динамически определять наборы с помощью специфического имени, а затем это имя может использоваться внутри запроса. Представьте себе это имя как псевдоним, назначенный для совокупности кортежей, представляющей собой набор, который можно использовать для извлечения данных. Набор, для которого назначен псевдоним, называют именованным набором (named set). Таким образом, именованный набор — это просто псевдоним для обычного MDX выражения, описывающего набор. {[Measures]. Кол проданного],[Measures]. Цена проданного товара]} - совокупность кортежей.

Запрос № 4

Запрос № 4 позволяет узнать общую прибыль и прибыль по каждому продукту. Общая прибыль составила — 67 620, «кабелей» проданного на сумму 32 и «твиксов» — 56 190. Вычисляемый член «Profit» (Прибыль) определен как произведение [Кол Проданного] и [Цена проданного Товара]. При выполнении данного запроса для каждой страны вычисляемый член будет по лучен на основе вычисления MDX выражения.

Запрос № 5

Данный запрос № 5 отражает информацию:

1. Итоги продаж по всем месяцам, с выведением по определённому товару.

2. Продажи за март месяц, где продано было только 6 штук «Твикса».

3. Продажи за месяц Апрель, где продано было 2 кабеля и 4 «Твикса».

4. Продаж за месяц Апрель не было.

Заключение

В рамках работы было выполнено:

· Изучены основные этапы процесса оценки эффективности супермаркета

· Разработано хранилище данных, содержащее данные по оценки эффективности работы торгового предприятия

· С помощью хранилища данных был проведен анализ эффективности работы супермаркета.

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

1. С. Я. Архипенков, Д. В. Голубев, О. Б. Максименко. «Хранилища данных». М: Диалог-МИФИ.- 2002 г.

2. http://microsoftbi.ru/tag/integration-services/

3. https://msdn.microsoft.com/ru-ru/default.aspx

4. http://static.ozone.ru/multimedia/book_file/1 003 100 463.pdf