Хранилища данных

 

 Учреждение «Университет  Туран»

Факультет АКТ

Кафедра компьютерная и программная  инженерия

 

 

 

 

 

 

 

 

 

 

 

Реферат по дисциплине «Методы  анализа ДиЗ»

на тему «Хранилища данных»

 

 

 

 

 

 

 

 

 

Выполнил 

ст. гр. ВТПО-12-1у

Казаков И.

 

Проверил 

Вердиев В.Г.

 

 

 

Алматы, 2013

 

СОДЕРЖАНИЕ

 

1. ВВЕДЕНИЕ
2. ХРАНИЛИЩА ДАННЫХ
3. АРХИТЕКТУРА БАЗ ДАННЫХ ДЛЯ ХРАНИЛИЩА
4. ВИТРИНЫ ДАННЫХ
5. ЗАКЛЮЧЕНИЕ

 

1. ВВЕДЕНИЕ

 

 

Принципы, лежащие в основе систем поддержки принятия решений, не позволяют эффективно обрабатывать транзакции, поэтому данные, применяемые  для анализа, стали выделять в  отдельные базы данных. Впоследствии эти базы стали называть хранилищами  данных или информационными хранилищами. В литературе используется также  англоязычный термин «Data Warehouse». Отцом  концепции использования хранилищ данных считают Билла Инмона. Большое  влияние на разработку концепции  хранилищ данных оказала американская корпорация «IBM».

Концепции хранилищ данных – это концепция подготовки данных для анализа. Она предполагает выполнение следующих положений:

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

 

 

2. ХРАНИЛИЩА ДАННЫХ

 

 

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

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

1. Обработка данных, генерируемых транзакциями.
2. Обеспечение высокого уровня точности путем избавления от избыточности данных.
3. Гарантирование целостности информации и данных.
4. Производство разовых документов и отчетов.
5. Увеличение эффективности работы за счет параллельной обработки и оптимизации запросов.

Выше перечисленные цели достигаются за счет хранения баз  данных в третьей нормальной форме.

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

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

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

База данных превращается в пространственную базу данных(dimensional database),отвечающую особой схеме либо структуре. Базы данных OLAP используются для построения кубов данных(data cube), являющихся многомерными представлениями  данных, которые обеспечивают коммерческий анализ в реальном времени и высокую  скорость обработки запросов.

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

Хранилище используется в  самых разных отраслях.

крупные производства- анализ тенденции в области сбыта, в  частности, сезонных колебаний объемов  продаж может помочь компании эффективно спланировать производство, разгрузить склады и сэкономить деньги;

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

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

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

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

 

 

3. АРХИТЕКТУРА БАЗ ДАННЫХ ДЛЯ ХРАНИЛИЩА

 

 

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

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

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

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

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

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

1. Категория. Категория продаваемого товара. В хранилище содержаться данные о 24 категориях товаров.
2. Производитель. Производитель конкретного товара. Компания может торговать товарами 50 разных производителей.
3. Клиент. Покупатель товаров. У компании три сотни клиентов.
4. Регион. Регион страны, в котором продаются товары. Рассматриваются три региона.
5. Месяц. Месяц, в котором были проданы товары. Для сравнительного анализа руководство компании решило ограничится хранением данных за последние 36 месяцев.

Полученный куб данных содержит 38880000 ячеек (24 категории*50 производителей*300 клиентов* 3 региона* 36 месяцев=38880000 ячеек).

Схема «звезда» является самым  эффективным способом моделирования N-мерного куба фактов для фактов для большинства хранилищ данных. Рассмотрим построение пространственной базы данных для реализации задачи анализа, используя этот подход. Каждое измерение куба представлено таблицей его значений. В нашем случае таких  таблиц пять: CATEGORIES, SUPPLIERS, CUSTOMERS, REGIONS и MONTHS. Для каждого значения измерения  в таблице имеется отдельная  строка. Например в таблице MONTHS 36 строк, по одной для каждого месяца всего  периода, за который анализируются  данные о продажах. А в таблице REGIONS три региона представлены тремя  строками.

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

У таблицы измерения всегда имеется первичный ключ индексирующий  значения этого измерения. В нашем  учебном хранилище будем использовать в качестве ключевых полей настоящие  значения измерений в таблице REGIONS («Запад», «Восток», и т.д.), CATEGORIES («Одежда», «Обувь» и т.д.) и MONTHS. Остальные  два измерения будут индексироваться  по кодам – поле CUST_CODE в таблице CUSTOMERS и поле SUPP_CODE в таблице SUPPLIERS.

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

 

Таблица №1- Схема «звезда» учебного хранилища данных для реализации задачи анализа

 

Для получения схемы данных рассмотрим типичные запросы:

Показать итоговые объемы продаж одежды за январь по регионам.

 

SELECT SUM (SALES_AMOUNT), REGION

FROM SALES, REGIONS

WHERE MONTH = ‘Январь 2008’ AND

PROD_TYPE = ‘ОДЕЖДА’ AND SALES.REGION = REGIONS.REGION

GROUP BY REGION

ORDER BY REGION

 

Показать средний объем  продаж товаров каждого производителя по клиентам и по месяцам

 

SELECT AVG (SALES_AMOUNT) . CUST_NAME,

SUPP_NAME, MONTH

FROM SALES, CUSTOMERS, SUPLIERS

WHERE SALES. CUST_CODE = CUSTOMERS. CUST_CODE

AND SALES. SUPP_CODE = SUPPLIERS. SUPP_CODE

GRUPE BY CUST_NAME, SUPP_NAME, MONTH

ORDER BY CUST_NAME, SUPP_NAME, MONTH

 

Другая схема пространственной базы данных называется схемой снежинки.

 

 

Таблица №2- Особенности  схемы «снежинка» пространственной базы данных

 

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

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

 

 

4. ВИТРИНЫ ДАННЫХ

 

 

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

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