Автор работы: Пользователь скрыл имя, 22 Октября 2013 в 22:28, курсовая работа
В данной работе я рассмотрела проектирование фактографических баз данных и хранилищ данных. Классифицировала различные подходы к проектированию БД, а так же рассмотрела этапы нисходящего подхода к проектированию БД. Целью данной работы является так же рассмотрение проектирования схем разных типов. В данной работе не акцентирую своё внимание на фактографических ИС.
1. Подходы к проектированию баз данных 3стр.
2. Фактографические базы социальных данных 4стр.
3. Этапы нисходящего подхода к проектированию баз данных 9стр.
3.1. Методология концептуального проектирования базы данных 9стр.
3.2. Методы логического проектирования баз данных реляционного типа 15стр.
3.3. Методология физического проектирования баз данных реляционного типа 23стр.
4. Проектирование хранилищ данных 35стр.
5. Проектирование схем типа „звезда" 40 стр.
6. Проектирование схем типа „звезда-снежинка" 40стр.
7. Проектирование схем типа „снежинка" 40стр.
4. Проектирование хранилищ данных
Хранилище данных – Предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.
Исходные данные, помещаемые в хранилище, поступают из следующих источников.
Менеджер загрузки (load manager), который часто называют внешним (front-end) компонентом, выполняет все операции, связанные с извлечением и загрузкой данных в хранилище.
Менеджер хранилища (warehouse manager) выполняет все операции, связанные с управлением информацией, помещенной в хранилище данных.
Менеджер запросов (query manager), который часто называют внутренним (back-end) компонентом, выполняет все операции, связанные с управлением пользовательскими запросами.
В части Детальные данные хранилища данных хранятся все детальные данные, описанные в схеме базы данных. В большинстве случаев детальные данные хранятся не на оперативном уровне, а в виде информации, обобщенной до следующего уровня детализации. Как правило, детальные данные периодически добавляются в хранилище с автоматическим выполнением обобщения исходной информации до необходимого уровня.
В области Частично и глубоко обобщенные данные хранилища размещаются все данные, предварительно обработанные менеджером хранилища с целью их частичного или глубокого обобщения (aggregate). Эта часть хранилища данных является временной, поскольку она постоянно подвергается изменениям в ответ на изменения профилей запросов.
Компонент Архивные и резервные копии хранилища данных отвечает за подготовку детальной и обобщенной информации к помещению в резервные и архивные копии.
В области Метаданные хранилища данных хранятся все те метаданные (данные про данные), которые используются любыми процессами хранилища.
Средства доступа к данным конечного пользователя могут быть:
В технологии хранилищ данных основное внимание уделяется управлению пятью основными информационными потоками: входным, восходящим, нисходящим, .выходным и метапотоком.С каждым из этих потоков связаны определенные процессы, которые представлены ниже.
Входной поток – Процессы, связанные с извлечением, очисткой и загрузкой информации из источников данных в хранилище данных.
Восходящий поток – Процессы, связанные с повышением ценности сохраняемых в хранилище данных посредством обобщения, упаковки и распределения исходных данных.
Нисходящий поток – Процессы, связанные с архивированием и резервным копированием информации в хранилище данных.
Выходной поток – Процессы, связанные с предоставлением данных пользователям.
Метапоток – Процессы, связанные с управлением метаданными.
Магазин (витрина) данных – Подмножество хранилища данных, которое поддерживает требования отдельного подразделения или деловой сферы организации. Магазин данных может быть независимым или определенным образом связанным с централизованным хранилищем данных.
Основные отличительные черты магазина данных от хранилища данных:
Метод проектирования базы данных как компонента хранилища или магазина данных, который называется моделированием размерностей (dimensionality modeling)
При проектировании базы данных для хранилища или магазина данных необходимо иметь представление о том, как они будут использоваться. База данных должна быть спроектирована таким образом, чтобы произвольные запросы пользователей выполнялись с приемлемой производительностью. В хранилище данных большое количество запросов будет относиться к детальным данным, которые могут анализироваться самыми разными способами.
5. Проектирование схем типа „звезда"
Схема "звезда" – Логическая структура, в центре которой находится таблица фактов (с детальными данными), окруженная таблицами размерностей (со ссылочными данными).
Схема "звезда" обладает логической структурой, в центре которой находится таблица фактов с детальными данными, окруженная справочными данными, помещенными в таблицы размерностей. Таблица фактов содержит внешний ключ для каждой таблицы размерностей. Эта структура отражает то, что фактические данные были созданы некими событиями в прошлом и вряд ли изменятся, независимо от того, как они анализируются. Поскольку основная часть информации в хранилище данных представлена в виде фактов, то размер таблицы фактов гораздо больше размера таблиц размерностей. Поэтому важно рассматривать факты как справочные данные, доступные только для чтения и неизменные с течением времени.
Для выделения фактических данных из данных размерностей необходимо установить основные транзакции внутри каждого бизнес-приложения. Для каждой таблицы фактов следует определить ключевые размерности, которые будут использоваться для всех фактов.
Основная цель проектирования таблиц фактов заключается в том, чтобы найти компромисс между ценностью хранимых данных и стоимостью их хранения. Размер таблиц фактов может быть огромным и превышать 1 терабайт (1012 байт). Поэтому для оптимального проектирования базы данных необходимо учесть факторы, перечисленные ниже.
Завершив создание таблицы фактов, следует приступить к проектированию таблиц размерностей. Для хранения этих таблиц обычно требуется гораздо меньше пространства, поскольку они существенно меньше (< 5 ГБ) таблиц фактов. По этой же причине перестройка таблиц размерностей является менее затратной процедурой, но только при условии, что первичные ключи таблиц фактов остаются неизменными.
Схема "звезда" может использоваться для повышения производительности выполнения запросов путем денормализации справочной информации с образованием единой таблицы размерностей. Измерения в схеме "звезда" обычно проектируются на основе известного использования данных обычными запросами, тогда как большая часть новых запросов, вероятно, будет выполняться за счет анализа таблицы фактов с учетом некоторых ограничений, установленных для единственной размерности.
Выполнение запросов может быть ускорено за счет размещения всей ограничивающей информации в одной таблице. На практике эта цель достигается с помощью денормализации всех дополнительных данных, связанных с сущностью, в единую таблицу размерности в схеме "звезда".
6. Схема „снежинка"
Схема "снежинка" – Вариант схемы "звезда", в котором каждая размерность может иметь свои собственные размерности.
В этом случае таблицы размерностей не содержат денормализованных данных.
7. Схема „звезда-снежинка"
Схема "звезда-снежинка" – Гибридная структура, которая включает комбинацию денормализованной схемы "звезда" и нормализованной схемы"снежинка".
В этом случае некоторые размерности могут быть представлены в обеих формах для удовлетворения потребностей разных запросов.
Список использованной литературы