Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Тема 4. Базы и хранилища данных
1. Основные этапы проектирования базы данных (БД), логическая и физическая модели данных, трехуровневая архитектура ANSI/SPARC.
2. Модели баз данных (иерархическая, сетевая реляционная и др.).
3. Формализованное описание отношений, ER-диаграмма.
4. Манипулирование данными в реляционной модели, операции реляционной алгебры.
5. Оптимизация схем отношений, нормальные формы, построение рациональной схемы отношений путем нормализации.
6. Язык SQL, типы данных и основные категории команд языка SQL.
7. Проектирование реляционных баз данных с использованием семантических моделей.
8. Основы технологии хранилищ данных (ХД). Транзакционные (OLTP) и аналитические (DSS) системы.
Предисловие: Для того чтобы обеспечить возможность анализа накопленных данных, организации стали создавать хранилища данных, которые представляют собой интегрированные коллекции данных, которые собраны из различных систем оперативного доступа к данным.
Концепция хранилища данных была задумана как технология, способная удовлетворить требования систем поддержки принятия решений и базирующаяся информации, поступающей из нескольких различных источников оперативных данных.
Определение: Хранилище данных - Предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.
Хранилища данных становятся основой для построения систем принятия решений. Несмотря на различия в подходах и реализациях, всем хранилищам данных свойственны следующие общие черты:
ХД - базовая технология современных СППР.
Перечисленные технологии не являются взаимонезависимыми и используются совместно, дополняя друг друга специфическими функциями.
Предпосылки создания ХД: При обработке информации (финансовой, бухгалтерской, банковской, маркетинговой и др.) традиционным является разделение существующих задач на два широких класса:
№1. Операционная обработка данных и транзакционные системы
Определение: Транзакционные Системы (ТС) - системы или части информационных систем, ориентированные на операционную (системы операционной обработки данных), или транзакционную обработку данных;
(ПРОИЗВОДЯТ КУЧУ МУСОРА-ДАННЫХ)
Определение: Транзакция – логически целостная операция по обработке данных, обеспечивающаяся последовательностью взаимно обусловленных (логически связанных) простых операций с данными. В базе данных транзакция предполагает цепочку логически связанных изменений данных (обработка информации или происходит, т.е. вся последовательность операций выполнена), или не происходит (любая из последовательности операции выполнена быть не может). Во втором случае состояние базы данных возвращается к исходному состоянию).
Примеры: Учетные системы часто выполняют подобные цепочки операций, поэтому их часто называют транзакционными.
К этому классу относятся любые автоматизированные бухгалтерские или банковские системы, которые осуществляют учет и хранение первичной информации по работе предприятия или банка: операция перевода денежных средств с одного счета на другой предполагает согласованное изменение данных одного счета и второго. Операция состоит из двух элементарных – уменьшить значение одного счета и увеличить значение другого.
OLTP: Системы обработки транзакций в реальном времени называются On-line Transaction Processing Systems (OLTP).
Для чего нужны: Системы OLTP предназначены для автоматизации повседневных задач, решаемых персоналом «нижнего» звена финансовых органов, банков или других учреждений (учет платежей в бюджет, учет расходов бюджета, клиентов, договоров, заказов, взаиморасчетов, запасов и пр.). Типичным примером OLTP – систем является «1С-Бухгалтерия».
Что делают: OLTP системы производят "горы" информации и соответственно оптимизированы на обработку больших объемов данных, выполнение сложных транзакций и интенсивных операций чтения/записи небольших порций данных.
№2. Задача анализа данных или задача принятия решений
Решением задач этого вида занимаются Аналитические системы.
Определение: Аналитические Системы (АС) - системы или составляющие части информационных систем, ориентированные на анализ данных. Их часто называют системами поддержки принятия решений (СППР).
Определение: Это совокупность интеллектуальных информационных приложений и инструментальных средств, которые используются для манипулирования данными, их анализа и предоставления результатов такого анализа конечному пользователю.
ХД – большая «куча мусора», в которой ищутся модели закономерностей инструментами BI (Business intelligence).
Для чего нужны: Основная цель - помочь управляющему персоналу организации принять правильное и своевременное решение (в зарубежной литературе им соответствует термин DSS - Decision Support System).
Требования к информации для AС:
9. Логические и физические модели данных ХД для аналитических информационных систем.
Логическая модель
Физическая модель
Физическая модель:
Одним из направлений развития РБД для систем принятия решений является разработка таблиц с денормализованной структурой (схемы «звезда» и «снежинка»).
Структура такой базы данных не будет чисто реляционной - это будет пространственная база данных, построенная с целью анализа данных, а не оптимизации выполнения транзакций и занимаемого места на носителях данных.
Звезда: В многомерном моделировании существует стандарт физической модели, называемый схемой звезда (star schema), которая обеспечивает высокую скорость выполнения запроса посредством денормализации и разделения данных.
Схема звезда строится так, чтобы обеспечить наивысшую производительность при выполнении одного самого важного запроса, либо для группы похожих запросов.
Схема звезда обычно содержит одну большую таблицу, называемую таблицей фактов (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта - дочерней.
Схема звезда может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности - дочерними.
Таблица фактов и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу факта в качестве внешних ключей. Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Таблицы измерений содержат неизменяемые либо редко изменяемые данные (типа справочник).
Снежинка: Если хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema).
Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table).
Консольные таблицы могут быть связаны только таблицами размерности, причем консольная таблица в этой связи родительская, а таблица размерности - дочерняя. Связь может быть идентифицирующей или неидентифицирующей.
Консольная таблица не может быть связана таблицей факта. Она используется для нормализации данных в таблицах размерности.
Нормализация данных полезна при моделировании реляционной структуры, но она уменьшает эффективность выполнения запросов к хранилищу данных. В размерной модели главной целью является обеспечение высокой эффективности просмотра данных и выполнения сложных запросов.
Схема снежинка обычно препятствует эффективности, потому что требует объединения многих таблиц для построения результирующего набора данных, что увеличивает время выполнения запроса. Поэтому при проектировании не следует злоупотреблять созданием множества консольных таблиц.
Гиперкуб:
Определение: Гиперкуб OLAP - это структура, в которой хранятся совокупности данных, полученные из базы данных OLAP путем всех возможных сочетаний значений измерений с фактами в таблице фактов. Исходя из этого, создание окончательного отчета выполняется гораздо эффективнее, поскольку не требует выполнения никакого сложного запроса.
В многомерной модели измерения (dimensions) соответствуют осям куба, а анализируемые переменные(меры) (measures) или показатели – индивидуальным ячейкам куба.
Многомерная модель позволяет делать плоские срезы куба данных и поворачивать его нужной гранью любым удобным нам образом.
Используя многомерную модель, аналитик может легко получить представление данных в соответствии с собственными интересами.
Основные составляющие логической модели «Многомерный гиперкуб»
Данные, в гиперкубе, можно поделить на четыре категории:
Мера (факты) — это численное значение (числовой показатель), выражающее определенный аспект деятельности организации и , используемые в базовой и возвратной информации, поэтому таблицы, содержащие данные мер, называются таблицами фактов.
Показатель - это величина (обычно числового типа), которая собственно и является предметом анализа (информация, представляемая этим значением, используется для принятия решения или оценки эффективности работы организации).
Ячейка (cell) - атомарная структура куба, соответствующая конкретному значению некоторого показателя.
Измерение (dimension) — это способ ранжирования данных, используемый для разделения агрегированных мер на составляющие их части.
Измерения позволяют ранжировать агрегированную меру. Ранжирование дает возможность видеть составные элементы агрегированных мер. Например, меру «общая сумма продаж» можно разделить на суммы продаж за каждый год, месяцы, дни.
Измерение (dimension) - это множество объектов одного или нескольких типов, организованных в виде иерархической структуры и обеспечивающих информационный контекст числового показателя. Измерение принято визуализировать в виде ребра многомерного куба.
Измерения играют роль индексов, используемых для идентификации значений показателей, находящихся в ячейках гиперкуба.
Атрибут (attribute) — это дополнительный элемент информации, относящийся к измерению и не являющийся при этом уникальным идентификатором или описанием этого измерения.
Атрибуты также служат для хранения информации, которая может применяться для ограничения или фильтрации записей, выбираемых из витрины данных в ходе анализа данных. Атрибуты хранятся в дополнительных столбцах таблиц измерений.
Иерархии необходимы для определения порядка и возможности агрегации и детализации значений показателей. Иерархии применяются для организаций измерений в многоуровневые структуры.
Если меры определяют что хотят видеть аналитики, то измерения и иерархии определяют, как они это хотят видеть.
Существуют следующие типы иерархий:
Архитектуры OLAP (отличаются методами хранения кубов данных)
MOLAP является многомерным форматом хранения данных, который отличается высоким быстродействием. Помимо поддержки OLAP самих кубов данных при выборе данного формата данные будут храниться в многомерных структурах на OLAP-сервере (OLAP-структуры).
MOLAP обеспечивает наилучшее быстродействие выполнения запросов, поскольку этот формат специально оптимизирован для многомерных запросов к данным.
ROLAP. Реляционные хранилища OLAP содержат данные, передаваемые в кубы данных, вместе с агрегациями данных куба, причем данные хранятся в реляционных таблицах, размещенных в реляционном ХД.
HOLAP. Гибридная архитектура, которая объединяет технологии ROLAP и MOLAP. Серверы HOLAP применяют подход ROLAP для разреженных областей многомерного пространства и подход MOLAP — для плотных областей.
Серверы HOLAP разделяют запрос на несколько подзапросов, направляют их к соответствующим фрагментам данных, комбинируют результаты, а затем предоставляют результат пользователю.
10. Программные средства реализации OLAP систем и их использование при построении аналитических информационных систем.
В настоящее время на рынке представлено большое количество OLAP-систем, производимых разными фирмами:
SQL 2005 – компоненты:
В комплекс средств интеллектуальной обработки данных SQL Server 2005 :