КОНЦЕПЦИИ ХРАНЕНИЯ ДАННЫХ

Учебная дисциплина
«Хранилища данных»
Лекция 2
КОНЦЕПЦИИ ХРАНЕНИЯ ДАННЫХ
Учебные вопросы:
1 Концепция хранения в реляционных базах
данных
2 Концепция организации хранилищ данных
3 Концепция организации многомерной модели
данных
Литература
1. Малыхина М.П. Базы данных: основы,
проектирование, использование. – Спб.: БХВПетербург, 2004. – 512 с.
2. Бергер А.Б. Microsoft SQL Server 2005 Analysis
Services. OLAP и многомерный анализ данных /
Бергер А.Б, Горбач И.В., Меломед Э.Л, Щербинин
В.А., Степаненко В.П. / Под общ. Ред. А.Б. Бергера,
И.В. Горбач. – СПб.: БХВ-Петербург, 2007. – 928 с.
3. Барсегян А.А. Методы и модели анализа
данных: OLAP и Data Mining / Барсегян А.А.,
Куприянов М.С., Степаненко В.В., Холод И.И. –
СПб.: БХВ-Петербург, 2004. – 336 с.
Цель лекции
Цель
лекции
–
сформировать
представление у студентов об основных
концепциях организации реляционных баз
данных, хранилищ и витрин данных,
построении многомерных моделей в
системах
оперативного
и
интеллектуального анализа данных.
1 Концепция хранения в реляционных базах
данных
В настоящее время реляционные БД занимают
доминирующее положение. С математической точки
зрения
реляционная
БД
представляет
собой
ограниченный набор конечных отношений различной
арности на множестве элементарных данных. Над
отношениями
можно
осуществлять
различные
алгебраические операции. Теоретическое обоснование
реляционной
модели,
выполненное
Э.Коддом,
отличается
использованием строгих принципов
математики и точностью. Все данные в модели
размещаются в таблицах [1].
Трехуровневая архитектура описания данных
включает следующие уровни абстракции: внешний,
внутренний и концептуальный (рисунок 1).
Пользователи
П1
П2
•••
ПN
Внешний уровень
С
Концептуальный уровень
У
Б
Внутренний уровень
Д
База данных
Рисунок 1 – Трехуровневая архитектура описания БД
Представление БД с точки зрения пользователя является
внешним уровнем представления. Каждый пользователь
выделяет
в
моделируемой
предметной
области
интересующие его сущности, атрибуты и связи. Формируя своё
представление о предметной области, выражает их в
наиболее удобной для себя форме. При этом одни и те же
данные у различных пользователей могут отображаться поразному. Таким образом, каждый пользователь при работе
имеет своё представление о БД ( ) и может использовать свой
язык программирования запросов или специальный язык,
поддерживаемый приложением.
Концептуальный
уровень
обеспечивает
представление данных в абстрактной форме. Описание БД на
концептуальном
уровне
является
результатом
концептуального проектирования и включает логическое
описание всех элементов данных и отношений между ними,
логическую структуру БД.
На внутреннем уровне область хранения данных
представляется
как
бесконечное
линейное
адресное
пространство. Внутреннее представление описывает физическую
реализацию БД и содержит:
• распределение дискового пространства для хранения данных;
• описание подробностей сохранения записей;
• сведения о размещении записей;
• сведения о сжатии данных и выбранных методах их
шифрования.
Осуществляется взаимодействие СУБД с методами доступа
операционной системы на внутреннем уровне.
Структура БД OLTP-систем в высокой степени нормализована и
состоит из множества таблиц, связанных между собой
посредством внешних ключей. Нормализованная структура
обеспечивает высокую производительность при поиске и
обработке единичных записей.
Scientific_Teacher
Scientific_work
Work_ID: int
Name: char(250)
Balls_for_one: float
upsize_ts: timestamp
id: decimal(18,0)
pps_id: int
Kafedra_ID: int
Faculty_kod: int
Work_ID: int
Year: int
Value: int
Comments: char(200)
Name: char(250)
Sub_faculty
Faculty
Methodic_Teacher
Faculty_ID: int
Kafedra_ID: int
Faculty_kod: int
Dekan: nvarchar(100)
Telefon_faculty: nvarchar(20)
Faculty_name: nvarchar(50)
Faculty_short_name: nvarchar(50)
Year: int
Name: char(250)
ZavKafedra: nvarchar(50)
Short_name: nvarchar(15)
Telefon: char(15)
Year: int
Teacher
personid: int
Kafedra_ID: int
Faculty_kod: int
id: decimal(18,0)
Edition_ID: int
pps_id: int
Kafedra_ID: int
Faculty_kod: int
Work_ID: int
Year: int
familia: nvarchar(50)
imya: nvarchar(50)
otchestvo: nvarchar(50)
passport_number: nvarchar(20)
organ: nvarchar(100)
passport_data_vyd: datetime
obrazovanie: nvarchar(50)
address: nvarchar(100)
Methodic
Edition_ID: int
Work_ID: int
Authers: char(200)
Name: char(250)
Publish: char(250)
Page_count: int
Year_publish: int
Methodic_work
Work_ID: int
Name: char(250)
Balls_rating_K: float
Balls_rating_A: float
Educational_Teacher
Quality_Teacher
Qualification
Pokazatel_ID: int
Name: char(250)
Balls_rating_A: float
Balls_rating_K: float
id: decimal(18,0)
pps_id: int
Kafedra_ID: int
Faculty_kod: int
Pokazatel_ID: int
Year: int
Value: int
Comments: char(200)
id: decimal(18,0)
pps_id: int
Kafedra_ID: int
Faculty_kod: int
Work_ID: int
Year: int
Value: int
Comments: char(200)
Educational_work
Work_ID: int
Name: char(250)
Balls_for_one: float
Index_train: float
Рисунок 2 – Фрагмент логической структуры БД
Valuation Works
2 Концепция организации хранилищ данных
Основой концепции хранилищ данных (ХД)
является необходимость разделения наборов
данных, предназначенных для транзакционной
обработки, и наборов данных для анализа в
системах поддержки принятия решений (СППР).
Это разделение осуществляется интеграцией,
согласованием и агрегацией разъединенных
данных из OLTP-систем и внешних источниках
данных в ХД.
Автор концепции W. Inmon определяет ХД
как
предметно-ориентированные,
интегрированные,
неизменчивые,
поддерживающие
хронологию
средства
хранения данных [2,3].
Концепция
ХД
обеспечивает
единую
модель
представления данных предприятия, организации и
реализацию интегрированного источника данных. В
соответствие с этой реализацией в ХД собираются данные из
транзакционных БД и других источников. В ХД
поддерживается хронология данных: сохраняются данные о
времени. Концептуально модель ХД можно представить в
виде схемы на рисунке 3. Данные из различных источников
помещаются в ХД, а их описания в репозиторий метаданных.
Пользователь, используя средства визуализации, построения
отчетов, статистической обработки и другие, анализирует
данные в хранилище. Выбор средств работы пользователя с
ХД теоретически не должен влиять на его структуру и
функции поддержания в актуальном состоянии. Физическая
реализация приведённой концептуальной схемы может быть
самой разнообразной.
Данные
Операционные
системы
Хранилище
данных
Предоставление
информации
Информация
Источники данных
Внешние
источники
Запрос
Репозиторий
метаданных
Требование
Приложение
пользователя
Метаданные
Рисунок 3 – Концептуальная модель хранилища данных
ВИРТУАЛЬНОЕ ХД эмулируют работу с данными в
информационной системе, как с хранилищем данных.
Виртуальное ХД можно организовать, создав ряд
«представлений» (view) в БД или применив специальные
средства доступа.
Главными достоинствами такого подхода являются
простота и малая стоимость реализации, единая платформа с
источником информации, отсутствие сетевых соединений
между источником информации и ХД.
Существенный недостаток в том, что создается не ХД как
таковое, а иллюзия его существования. Структура хранения и
само хранение не претерпевают изменений, и остаются
проблемы
с
производительностью
системы,
трансформацией данных, интеграцией данных с другими
источниками, отсутствие истории и чистоты данных,
зависимость от характеристик основной БД.
Известна ДВУХУРОВНЕВАЯ АРХИТЕКТУРА ХД, предполагающая
построение витрин данных (Data mart) без создания
центрального хранилища. При этом вся информация,
поступающая
из
OLTP-систем,
ограничена
конкретной
предметной областью. При построении витрин данных
используются основные принципы построения ХД, которые
можно рассматривать как ХД в миниатюре.
Достоинства этого подхода состоит в простоте и малой
стоимости реализации, высокой производительности за счет
физического разделения регистрирующих и аналитических
систем, поддержке истории данных и возможности добавления
метаданных. Концепция витрин данных предложена Forrester
Research в 1991 году [4]. Главная идея витрин данных –
сохранение
тематического
подмножества
заранее
агрегированных данных. Размер тематического подмножества
данных намного меньше множества данных ХД, что значительно
снижает
уровень
требования
к
производительности
компьютерной техники.
Построение ХД предприятия, как правило, выполняется в
трехуровневой архитектуре.
На первом уровне расположены разнообразные источники данных
и справочные системы.
Второй уровень ХД содержит центральное хранилище и, возможно,
оперативный склад данных.
В центральном хранилище
консолидируется информация от всех источников с первого уровня.
Оперативный склад данных не содержит исторических данных и
выполняет две функции: хранения аналитической информации для
оперативного управления и подготовки данных для последующей
загрузки в центральное хранилище.
Третий уровень ХД представляет собой набор предметноориентированных витрин данных, данные в которые загружаются из
центрального хранилища данных. Таким образом, ХД представляет
собой предметно-ориентированное, интегрированное, связанное со
временем и неизменное во времени собрание данных. Предметная
ориентация коллекции данных означает, что данные отражают
существенные аспекты деятельности организации. Интеграция данных
предполагает
собрание
данных
в
целостную
структуру,
обеспечивающую анализ данных.
Основными составляющими структуры хранилищ данных
являются таблица фактов (Fact table) и таблицы измерений
(Dimension tables).
Таблица фактов. Таблица фактов является основной таблицей
хранилища данных. Как правило, она содержит сведения об
объектах или событиях, совокупность которых будет в
дальнейшем анализироваться. Обычно выделяют четыре
встречающихся типа фактов:
• факты, связанные с транзакциями (Transaction facts). Они
основаны на отдельных событиях;
• факты, связанные с «моментальными снимками» (Snapshot
facts). Основаны на состоянии объекта;
• факты, связанные с элементами документа (Line-item facts).
Основаны на том или ином документе;
• факты, связанные с событиями или состоянием объекта (Event
or state facts), представляюobt возникновение события без
подробностей.
Таблица фактов, которая может быть построена на основе БД
Valuation Works, приведена на рисунке 4. В рассматриваемом
примере измерениям будущего куба соответствуют первые
шесть полей, а агрегатным данным — последние четыре. В
таблице фактов нет никаких сведений о том, как группировать
записи при вычислении агрегатных данных. В ней есть
идентификаторы продуктов или клиентов. Эти сведения, в
дальнейшем используемые для построения иерархий в
измерениях куба, содержатся в таблицах измерений.
Work_Fact
Zvanie: int
pps_id: int
Kafedra_ID: int
Faculty_kod: int
Pokazatel_ID: int
Stepeny_ID: int
Doljnosty_ID: int
Year: int
Value: int
Рисунок 4 – Пример таблицы фактов
Таблицы измерений содержат неизменяемые либо редко
изменяемые данные. В подавляющем большинстве случаев эти
данные представляют собой по одной записи для каждого члена
нижнего уровня иерархии в измерении. Таблицы измерений
также содержат как минимум одно описательное поле (обычно с
именем члена измерения) и, как правило, целочисленное
ключевое поле (обычно это суррогатный ключ) для однозначной
идентификации члена измерения. Если будущее измерение,
основанное на данной таблице измерений, содержит иерархию,
то таблица измерений также может содержать поля,
указывающие на «родителя» данного члена в этой иерархии.
Таблица измерений может содержать и поля, указывающие на
«прародителей», и иных «предков» в данной иерархии. Каждая
таблица измерений должна находиться в отношении «один ко
многим» с таблицей фактов (рисунок 5).
Teacher_Dim
personid: int
Kafedra_ID: int
Faculty_kod: int
familia: nvarchar(50)
imya: nvarchar(50)
Рисунок 5 – Пример таблицы измерений
Одно измерение куба может содержаться как в одной
таблице, так и в нескольких связанных таблицах,
соответствующих различным уровням иерархии в измерении
(рисунок 6). Если каждое измерение содержится в одной
таблице, такая схема хранилища данных носит название
«звезда». Если же хотя бы одно измерение содержится в
нескольких связанных таблицах, такая схема хранилища данных
носит название «снежинка».
Degree_Dim
Faculty
Degree_Id: int
Faculty_Id: int
Dekan: nvarchar(100)
Telefon_faculty: nvarchar(20)
Faculty_name: nvarchar(50)Sub_fakulty
Faculty_short_name: nvarchar(50)
Sub_fakulty_Id: int
Faculty_id: int
Name: char(250)
ZavKafedra: nvarchar(50)
Short_name: nvarchar(15)
Teacher_Dim
Name: char(250)
Balls_degree_A: float
Balls_degree_K: float
Teacher_Id: int
Sub_fakulty_id: int
Faculty_id: int
First_name: nvarchar(50)
imya: nvarchar(50)
otchestvo: nvarchar(50)
pol: nvarchar(8)
passport_seria: nvarchar(20)
passport_number: nvarchar(20)
Post_Dim
Post_Id: int
Name: char(250)
Balls_post_A: float
Balls_post_K: float
Work_Fact
Teacher_id: int
Sub_fakulty_ID: int
Faculty_id: int
Degree_id: int
Post_id: int
Status_id: int
Year: int
Value: int
Comments: char(200)
Рисунок 6 – Пример схемы «снежинка»
Status_Dim
Status_Id: int
Name: char(250)
Balls_status_A: float
Balls_status_K: float
3 Концепция многомерной модели данных
В службах SQL Server Analysis Services используется
унифицированная многомерная модель данных
(Unified Dimensional Model, UDM). Эта модель
позволяет различным клиентским приложениям
получить доступ к данным из реляционных и
многомерных БД без применения различных моделей
(рисунок 7). Роль унифицированной многомерной
модели заключается в создании моста между
пользователем и источниками данных [2, 3]. Модель
UDM конструируется на одном или нескольких
источниках данных. Пользователь запрашивает
модель UDM при помощи различных клиентских
средств, например Microsoft Excel.
Analysis
Services
(сервер UDM)
MDX/SQL
Клиентские
приложения
Реляционные
БД
Файлы с
данными
XMLA
UDM
ADO.NET,
OLE DB
Web – серверы
Рисунок 7 – Многомерная модель данных
Преимущества
унифицированной
многомерной
модели данных:
• значительно обогащает пользовательскую модель;
• обеспечивает
высокую
производительность
запросов, поддерживая интерактивный анализ даже на
очень больших объемах данных;
• использует в модели бизнес-правила для поддержки
более содержательного анализа данных;
• поддерживает «закрытие цикла»: пользователям
позволяется действовать с данными, которые они видят
на экране монитора.
• Многомерная
модель
данных
определяет
представление
данных
на
трех
уровнях:
концептуальной
модели;
физической
модели;
прикладной модели.
Физическая
модель
основывается
на
концептуальной модели. Как и в случае
реляционных БД, физическая модель определяет
условия хранения данных на физических
носителях:
• место хранения: тип файлов с данными,
носитель информации, размещение носителя;
• способ хранения: в сжатом или несжатом
виде, вид индексирования;
• правила доступа к данным, организацию
кеширования данных, способ занесения и
извлечения данных из памяти.
Страница (Page)
Поле 1
Поле 2
Поле №
Null Bits
Поле №
Null Bits
Поле №
Null Bits
Запись (Record) 2
Поле 1
Поле 2
••••
Запись (Record) N
Поле 1
Поле 2
Рисунок 8 – Структура записей и страниц
Для описания многомерного пространства
используются следующие термины:
измерение (dimension), описывающее элемент
данных для анализа;
• элемент (member): соответствует одной точке на
измерении.
• значение элемента (member value): уникальная
характеристика элемента;
• атрибут (attribute): полная коллекция элементов
одного типа;
• размер (size) или кардинальность (cardinality)
измерения:
количество
элементов,
которое
содержит измерение.
Метки (Members)
y2
y1
y3
x1
x2
x3
z
z3
U313
U323
U333
z2
U312
U322
U332
z1
U311
U321
U331
Пустая ячейка (Empty Cell)
y
Измерения (Dimensions)
Ячейка (Cell)
Мера (Measure)
x
Рисунок 9 – Трехмерное пространство данных
При описании многомерного пространства
дополнительно
используются
следующие
понятия:
• кортеж (tuple), определяющий координату в
многомерном модельном пространстве;
• срез
(slice),
определяющий
секцию
многомерного модельного пространства, которая
определяется кортежем.
Контрольные вопросы
1.
2.
3.
4.
5.
6.
7.
8.
Поясните сущность концепции хранения в реляционных базах
данных.
Перечислите и охарактеризуйте уровни представления данных
в реляционных базах данных.
Поясните сущность концепции организации хранилищ
данных.
Приведите концептуальную модель организации хранилищ
данных и поясните назначение её элементов.
Поясните сущность трехуровневой архитектуры построения ХД
Поясните сущность концепции организации многомерной
модели данных.
Приведите многомерную модель данных и поясните
назначение её элементов.
Поясните преимущества унифицированной многомерной
модели данных.