Реферат на тему:


Воспользуйтесь поиском к примеру Реферат        Грубый поиск Точный поиск






Загрузка...
хранилище данных

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

План

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

2. Многомерная модель хранилища

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

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

Хранилище данных (Data Warehouse, DW) - система, поддерживающая непротиворечивую интегрированную предметно-ориентированную совокупность исторических данных организации с целью поддержки

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

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

В основе концепции хранилищ данных лежит идея разделения на две группы данных, используемых: для оперативной обработки (OLTP) и для решения задач анализа (OLAP).

OLTP (On-Line Transaction Processing) - системы оперативной обработки транзакций, которые предназначены для поддержания текущей деятельности разного рода организаций.

OLAP (On-Line Transaction Processing) - системы оперативной аналитической обработки, которые предназначены для поддержки принятия решений и ориентированы главным образом на нерегламентированные запросы. Срок OLAP позволяет описывать технологию обработки данных, в которой применяется многомерное представление агрегированных данных для обеспечения быстрого доступа к данным для углубленного анализа.

Сравнительный анализ OLTP и OLAP систем приведены в табл. 12.1.

Архитектура современных хранилищ данных базируется или на использовании многомерной модели БД (Multidimension OLAP, MOLAP), либо на реляционной модели БД (Relational OLAP, ROLAP).

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

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

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

Data Mining - исследование и нахождение компьютером (средствами искусственного интеллекта) в данных скрытых

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

На рис. 12.1 показана логическая схема аналитической системы с хранилищем данных.

Многомерная модель хранилища

Многомерная модель предполагает, что данные хранятся не в виде плоских таблиц, как в реляционной БД, а в виде гиперкубов - упорядоченных многомерных массивов. Многомерное

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

В многомерной модели рассматриваются такие операции манипулирования данными:

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

- вращение, при котором изменяется порядок представления измерений;

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

- детализация - это операция обратная к сворачивание и обеспечивает переход от обобщенных данных в детализированных.

Многомерная СУБД лучше других систем выполняет сложные нерегламентированные запросы.

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

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

Все данные в хранилище данных делятся на категории:

- детальные данные;

- агрегированные данные;

- метаданные.

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

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

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

Последовательность проектирования хранилища данных показана на рис. 12.2.

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

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

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

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

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

- параметры, характеризующие деятельность вуза (количество студентов, конкурс и т.д.)

- описание вузов (название, факультеты, специальности и т.д.)

- момент времени (год, квартал, месяц и т.д.).

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

Примеры запросов к хранилищу данных: "Определить среднюю успеваемость студентов в технических университетах", "Как изменился конкурс студентов на экономические специальности за последние пять лет?»

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

Література

1. Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс. - М.: Гелиос АРВ, 2002. - 368 с.

2. Гайна Г.А. Організація баз даних і знань. Мови баз даних: Конспект лекцій.-К .:КНУБА, 2002. - 64 с.

3. Гайна Г.А., Попович Н.Л. Організація баз даних і знань. Організація реляційних баз даних: Конспект лекцій. - К.:КНУБА, 2000. - 76 с.

4. Гарсиа-Молина Г., Ульман Д., Уидом Д. Системы баз данных.-М.: Издательский дом "Вильямс", 2003. - 1088 с.

5. Григорьев Ю.А., Ревунков Г.И. Банки данных.-М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. - 320 с.

6. Грофф Дж., Вайнберг П. Энциклопедия SQL. - СПб.: Питер, 2003. - 896 с.

7. Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 1998. - 784 с.

8. Диго С.М. Проектирование и использование баз данных.-М.: Финансы и статистика, 1995. - 208 с.

9. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001. - 304 с.

10. Когаловский М.Р. Энциклопедия технологий баз данных.- М.: Финансы и статистика, 2002. - 800 с.

11. Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. - М.: Издательский дом "Вильямс", 2003. - 1440 с.

12. Кренке Д. Теория и практика построения баз данных. - СПб.: Питер, 2003. - 800 с.

13. Малыхина М.П. Базы данных: основы, проектирование, использование. - СПб.: БХВ-Петербург, 2004. - 512 с.

14. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. - СПб.: БХВ-Петербург, 2004. - 1040 с.

Загрузка...