 |
Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | |
Проектирование хранилищ данных
|
|
Проблемы эффективного использования данных. Корпоративные
системы управления предприятием, созданные на основе реляционных
СУБД, как правило, эффективно решают задачи учета, контроля и хранения
данных. Однако в силу своей специфики реляционная структура не позволя-
ет решать задачи анализа имеющейся информации с требуемой производи-
тельностью. Особенно остро эта проблема стоит в гетерогенных информа-
ционных средах, когда в центральном офисе организации и в филиалах экс-
плуатируются СУБД различных производителей (см. рис. 2. 3. 29 а).
Такая ситуация часто возникает либо в результате слияния компаний,
когда компания превращается в филиал более крупной компании, но при
этом нерентабельно перестраивать исторически сложившуюся информаци-
онную инфраструктуру, либо вследствие неудовлетворительного управле-
ния, когда филиалы не придерживаются корпоративного стандарта и вне-
дряют собственные ИС. Одной из основных задач, решаемых в корпоратив-
ных ИС, является предоставление аналитической информации, необходи-
мой для принятия решений. Для поддержки принятия решения необходим
не один заранее подготовленный отчет, а серия разнообразных отчетов, при-
чем менеджер не всегда представляет, какой именно отчет понадобится ему
в следующие полчаса. Например, при анализе продаж по компании оказыва-
ется, что в феврале текущего года произошел спад. Чтобы выяснить причи-
ны спада, необходимо просмотреть отчет о продажах в регионах. Отчет
о продажах в регионах показывает, что спад произошел, видимо, по причи-
не неудовлетворительной работы одного из филиалов, следовательно, необ-
ходим отчет о работе данного филиала и т. д. и т. п. Организовать выполне-
ние таких отчетов в гетерогенной среде крайне сложно. Для эффективного
анализа данных в этом случае необходимо объединять в одном запросе дан-
ные из разнородных источников. В настоящее время существуют мониторы
транзакций и генераторы отчетов (например, Crystal Reports), обладающие
такой функциональностью, однако производительность таких систем не мо-
жет быть высокой. В процессе анализа данные, необходимые для принятия
решений, должны поступать к потребителю в режиме реального времени.
Если же данные собираются из разных источников, то, во-первых, отчет го-
товится недопустимо медленно, во-вторых, другие приложения, работаю-
щие с реляционными СУБД во время выполнения отчета, скорее всего бу-
дут заметно замедляться.
Решением проблемы производительности является создание специализи-
рованной базы данных - хранилища данных (Data Warehouse), предназна-
ченной исключительно для обработки и анализа информации (рис. 2. 3. 29 б).
Хранилища данных позволяют разгрузить оперативные базы данных
и тем самым дают возможность пользователям более эффективно и быстро
извлекать необходимую информацию. Они могут быть включены в общую
корпоративную сеть, по которой в хранилище по заранее определенному
расписанию, как правило в период наименьшей загрузки сети и серверов
копируется накопленная за день или за неделю информация. Поскольку
данные меняются редко, то к хранилищу данных не предъявляются жесткие
требования, которые обычно предъявляются к обычным базам данных, - от-
сутствие аномалий при выполнении операций обновления или удаления
и избыточности хранения информации. По этой причине может сложиться
неверное представление, что проектировать хранилище проще, чем базу
данных, предназначенные для оперативной обработки информации. На са-
мом деле проектирование хранилища данных является весьма сложной за-
дачей.
• Менеджеру, принимающему решения, необходимы самые разнообраз-
ные отчеты, причем всякий раз новые. Не всегда возможно выделить
специалиста, который бы непрерывно готовил все новые и новые отче-
ты. Лучший выход - научить создавать отчеты самого менеджера. Суще-
ствуют разнообразные инструменты (например, упомянутый выше Crys-
tal Reports), интерфейс которых достаточно прост для того, чтобы не-
профессионалы в области информационных технологий могли создавать
отчеты. Однако в этом случае конечный пользователь непосредственно
обращается к структуре данных. Следовательно, структура данных хра-
нилища должна быть понятна пользователям.
• Данные в хранилище должны регулярно пополняться. Требуется тща-
тельно документировать правила пополнения и резервного копирования
данных. Должны быть выделены статические данные, которые модифи-
цируются по расписанию: ежедневно, еженедельно, ежеквартально.
• Поскольку отчет будет создавать конечный пользователь, должны быть
упрощены требования к запросам с целью исключения тех запросов, ко-
торые могли бы требовать множественных утверждений SQL в традици-
онных реляционных СУБД.
• Обработка запросов к хранилищу должна быть проведена с высокой
производительностью, желательно в реальном масштабе времени.
поэтому должна быть обеспечена поддержка сложных запросов SQL,
которые требуют последовательной обработки тысяч или миллионов
записей.
Очевидно, что для решения этой задачи необходимо использовать спе-
циальные инструментальные средства. ERwin является незаменимым инст-
рументом для проектирования хранилищ данных по нескольким причинам.
Хотя реализовать хранилище данных можно на любом сервере базы дан-
ных, существуют специализированные серверы, специально предназначен-
ные для поддержки хранилищ данных. ERwin поддерживает генерацию
схемы базы данных для двух таких серверов - Teradata и Red Brick.
Как было указано выше, при проектировании хранилища необходимо
создавать подробные спецификации для всех источников данных, в том
числе самых разных типов. ERwin поддерживает на физическом уровне
прямое и обратное проектирование объектов более чем для 21 типа баз дан-
ных, поэтому является идеальным CASE-средством для работы с гетероген-
ными ИС.
Для эффективного проектирования хранилищ данных ERwin использует
размерную (Dimensional) модель. Dimensional - методология проектирова-
ния, специально предназначенная для разработки хранилищ данных.
Рассмотрим основные особенности техники моделирования хранилищ
данных с помощью ERwin.
Поддержка методологии Dimensional. Нормализация данных в реляци-
онных СУБД приводит к созданию множества связанных между собой таб-
лиц. В результате выполнение сложных запросов неизбежно приводит
к объединению многих таблиц, что существенно увеличивает время откли-
ка. Проектирование хранилища данных подразумевает создание денормали-
зованной структуры данных (допускается избыточность данных и возмож-
ность возникновения аномалий при манипулировании данными), ориенти-
рованной в первую очередь на высокую производительность при выпол-
нении аналитических запросов. Нормализация делает модель хранилища
слишком сложной, затрудняет ее понимание и ухудшает эффективность вы-
полнения запроса.
Для эффективного проектирования хранилищ данных ERwin использует
Размерную модель (Dimensional). Dimensional - методология проектирова-
ния, специально предназначенная для разработки хранилищ данных. Моде-
лирование Dimensional сходно с моделированием связей и сущностей для
Реляционной модели, но отличается целями. Реляционная модель акценти-
руется на целостности и эффективности ввода данных. Размерная модель
(Dimensional) ориентирована в первую очередь на выполнение сложных за-
просов к базе данных.
В размерном моделировании принят стандарт модели, называемый схе-
мой "звезда" (star schema), которая обеспечивает высокую скорость вы-
полнения запроса посредством денормализации и разделения данных. Не-
возможно создать универсальную денормализованную структуру данных
обеспечивающую высокую производительность при выполнении любого
аналитического запроса. Поэтому схема "звезда" строится так, чтобы обес-
печить наивысшую производительность при выполнении одного самого
важного запроса либо группы похожих запросов.
Схема "звезда" обычно содержит одну большую таблицу, называемую
таблицей факта (fact table), помещенную в центр, и окружающие ее мень-
шие таблицы, называемые таблицами размерности (dimensional table), со-
единенные с таблицей факта в виде звезды радиальными связями. В этих
связях таблицы размерности являются родительскими, таблица факта - до-
черней. Схема "звезда" может иметь также консольные таблицы (outrigger
table), присоединенные к таблице размерности. Консольные таблицы явля-
ются родительскими, таблицы размерности - дочерними.
В размерной модели иконка показывает роль таблицы в схеме "звезда":
- таблица факта (fact table);
- таблица размерности (dimensional table);
- консольная таблица (outrigger table).
Прежде чем создать базу данных со схемой типа звезды, необходимо
проанализировать бизнес-правила предметной области с целью выяснения
центрального вопроса, ответ на который наиболее важен. Все прочие вопро-
сы должны быть объединены вокруг этого основного вопроса, и моделиро-
вание должно начинаться с этого основного вопроса. Данные, необходимые
для ответа на этот вопрос, должны быть помещены в центральную таблицу
модели - таблицу факта. Например, если необходимо создавать отчеты
об общей сумме дохода от продаж за определенный период как по типу то-
вара, так и по продавцам, следует разрабатывать модель так, чтобы каждая
запись в таблице факта представляла сумму продаж, осуществленных тем
или иным продавцом, с указанием доходов по каждому покупателю и типов
проданных товаров (рис. 2. 3. 30). В примере таблица факта содержит сум-
марные данные о продажах (SALE), а таблицы размерности содержат дан-
ные о заказчике и заказах (CUSTOMER), продуктах (PRODUCT), продавцах
(SALESPEOPLE) и периодах времени (TIME).
Таблица факта является центральной таблицей в схеме "звезда". Она мо-
жет состоять из миллионов строк и содержать суммирующие или фактиче-
ские данные, которые могут помочь ответить на требуемые вопросы. Она
соединяет данные, которые хранились бы во многих таблицах традицион-
ных реляционных баз данных. Таблица факта и таблицы размерности связа-
ны идентифицирующими связями, при этом первичные ключи таблицы раз-
мерности мигрируют в таблицу факта в качестве внешних ключей. В раз-
мерной модели направления связей явно не показываются - они определя-
ются типом таблиц. Первичный ключ таблицы факта целиком состоит
из первичных ключей всех таблиц размерности. В примере (таблица факта
SALE) первичный ключ составлен из четырех внешних ключей: Customer-
ID, SalespeoplelD, TimelD и ProductID.
Таблицы размерности имеют меньшее количество строк, чем таблицы
факта, и содержат описательную информацию. Эти таблицы позволяют
пользователю быстро переходить от таблицы факта к дополнительной ин-
формации.
В примере на рис. 2. 3. 30 таблица SALE - таблица факта; CUSTOMER,
TIME, SALESPEOPLE и PRODUCT- таблицы размерности, которые позволя-
ют быстро извлекать информацию о том, кто и когда сделал покупку, какой
продавец и на какую сумму продал и какие именно товары были проданы.
ERwin поддерживает использование вторичных таблиц размерности, на-
зываемых консольными таблицами (outrigger), хотя они не требуются для
схемы "звезда". Консольные таблицы могут быть связаны только с таблица-
ми размерности, причем консольная таблица в этой связи родительская,
а таблица размерности - дочерняя. Связь может быть идентифицирующей
или неидентифицирующей. Консольная таблица не может быть связана
с таблицей факта. Она используется для нормализации данных в таблицах
размерности. Нормализация данных полезна при моделировании реляцион-
ной структуры, но она уменьшает эффективность выполнения запросов
к хранилищу данных. В размерной модели главной целью является обеспе-
чение высокой эффективности просмотра данных и выполнения сложных
запросов.
Схема "снежинка" (так называется размерная модель, в которой кон-
сольные таблицы используются для нормализации каждой таблицы размер-
ности, рис. 2. 3. 31) обычно препятствует эффективности, потому что требует
объединения многих таблиц для построения результирующего набора дан-
ных, что увеличивает время выполнения запроса. Поэтому при проектиро-
вании не следует злоупотреблять созданием множества консольных таблиц.
Если денормализованная таблица размерности получается слишком
большой, при этом к части колонок запросы делаются чаще, чем к осталь-
ным, целесообразно для повышения эффективности разбить одиночную
таблицу размерности на две отдельные таблицы размерности. Две получен-
ные таблицы можно связать неидентифицирующей связью. В примере
на рис. 2. 3. 30 таблица размерности PRODUCT содержит как информацию
о конкретном товаре, так и информацию о типах товаров. Если запросы,
связанные с типами товаров, делаются чаще, чем по отдельным товарам,
можно создать новую таблицу PRODUCT_TYPE и перенести в нее инфор-
мацию о типах (рис. 2. 3. 32). В этом случае за счет того, что колонки, к ко-
торым наиболее часто обращаются запросы, переносятся в новую таблицу»
уменьшается время выполнения запроса.
ERwin поддерживает методологию размерного моделирования благодаря
использованию специальной нотации для физической модели - Dimensional.
Для переключения на нотацию Dimensional на физическом уровне
(на логическом уровне эта нотация недоступна) необходимо перейти в за-
кладку Notation (рис. 2. 3. 33) диалога Model Properties (меню Model/Model
Properties) и выбрать в группе Physical Notation опцию DM (Dimensional
Modeling). После переключения на нотацию Dimensional на диаграмме по-
казываются иконки размерности для таблиц.
Затем необходимо установить опцию отображения связей диагональны-
ми линиями (Orthogonal). (Устанавливается в группе Relationship lines за-
кладки General диалога Stored Displays, меню Format/Stored Display Setting).
Для внесения новой таблицы в модель можно воспользоваться кнопкой
в палитре инструментов. В диалоге описания свойств таблицы Tables
появляется новая закладка - Dimensional, в которой задаются специфиче-
ские свойства таблицы в размерной модели (рис. 2. 96). Перечислим их.
Роль таблицы в схеме (Dimensional Modeling Role). По умолчанию
ERwin автоматически определяет роль таблицы на основании созданных
связей (таблица факта, размерности или консольная). Таблица без связей
определяется как таблица размерности, таблица факта не может быть роди-
тельской в связи, таблица размерности может быть родительской по отно-
шению к таблице факта, консольная таблица может быть родительской
по отношению к таблице размерности. Для задания роли таблицы вручную
необходимо выключить опцию Calculate Automatically.
Тип таблицы размерности (Dimension Type). Каждая таблица размер-
ности может содержать неизменяемые либо редко изменяемые данные
(Slowly Changing). Поскольку хранилище данных имеет ненормализован-
ную структуру, редактирование таблиц размерности может привести к кол-
лизиям. Для того чтобы избежать противоречий при хранении данных,
ERwin позволяет задать тип редко изменяемых данных, который отличается
способом редактирования данных:
1. Перезаписывание старых данных новыми. При этом старые данные
теряются.
2. Создание новой записи в таблице размерности с новыми данными
и временем изменения. В этом случае сохраняются старые данные
и можно проследить историю изменения редактируемых данных,
но необходимо генерировать ключ для ссылки на старые данные.
3. Запись новых данных в дополнительном поле той же самой записи.
В этом случае сохраняется первоначальное и последнее новое значение.
Все промежуточные данные теряются.
Правила хранения данных (Data Warehouse Rules). Для каждой таб-
лицы можно задать 6 типов правил манипулирования данными: обновление
(Refresh), дополнение (Append), резервное копирование (Backup), восста-
новление (Recovery), архивирование (Archiving) и очистка (Purge). Для ус-
тановки правил следует в закладке Data Movement диалога Tables
(рис. 2. 3. 35) выбрать имя правила из соответствующего списка выбора.
Каждое правило должно быть предварительно описано в диалоге Data
Movement Rules (меню Model/Data Movement Rules) (рис. 2. 3. 36).
Список в верхней части диалога Data Movement Rules показывает все
описанные правила. Для каждого правила должно быть задано имя, тип, оп-
ределение (закладка Definition). Например, определение правила дополне-
ния данных может включать частоту и время дополнения (ежедневно, в кон-
це рабочего дня), продолжительность операции и т. д. Связать правила с оп-
ределенной таблицей можно не только с помощью диалога Tables, но и не-
посредственно из Data Movement Rules (закладка Attachment).
Создание спецификаций для источников данных. При проектирова-
нии хранилища данных важно определить источник данных (для каждой
колонки), метод, которым исходные данные извлекаются, преобразуются
и фильтруются, прежде чем они импортируются в хранилище данных. Хра-
нилище данных может объединять информацию из текстовых файлов
и многих баз данных, как реляционных, так и нереляционных, в единую
систему поддержки принятия решений.
Чтобы поддерживать регулярные обновления и проверки качества дан-
ных, необходимо знать источник для каждой колонки в хранилище данных.
Для документирования информации об источниках данных используется
редактор Data Warehouse Sources (рис. 2. 3. 37).
Внести новый источник можно, щелкнув по кнопке слева от имени
в списке источников. Источник данных может быть описан вручную в диа-
логе Data Warehouse Sources либо импортирован. Для импорта источника
следует щелкнуть по кнопке Impot. Появляется диалог Data Warehouse
Sources - Set Options (рис. 2. 3. 38). В качестве источника при импорте могут
быть использованы другие модели ERwin, хранящиеся в файле, SQL-
скрипты, модели, хранящиеся в репозитории ModelMart, либо системные
каталоги СУБД, на основе которых в результате обратного проектирования
могут быть созданы модели ERwin. Каждому источнику может быть задано
имя и определение.
В закладку Data Source редактора Columns (рис. 2. 3. 39) можно внести
информацию об использовании источников данных для каждой колонки
в таблице. В поле Transform Comment вносится дополнительная информа-
ция о переносе данных из источника в хранилище данных.
Для выбора источника данных следует щелкнуть по кнопке 
в правой
верхней части закладки Data Source. Появляется диалог Data Warehouse
Source Selector (рис. 2. 3. 40), в окне Available Sources которого показываются
все предварительно описанные источники. Для выбора источника следует
выбрать в списке необходимую колонку и щелкнуть по кнопке Select.
Рис. 2. 3. 39. Диалог Column Editor
Рис. 2. 3. 40. Диалог Data Warehouse Source Selector
Поддержка специализированных СУБД. Хотя хранилище данных
можно создать, используя любую СУБД, существуют специализированные
СУБД, позволяющие значительно увеличить производительность обработки
данных при использовании схемы "звезда". ERwin поддерживает на физиче-
ском уровне две такие СУБД - Red Brick и Teradata. При прямом и обратном
проектировании поддерживаются специфические свойства как Red Brick,
так и Teradata.
Для Red Brick поддерживаются специфические свойства индексов
(рис. 2. 3. 41):
• уникальность (unique);
• распределение по сегментам;
• FILLFACTOR;
• определение типа индекса BTREE (только для версии Red Brick 5. 0
и выше), STAR или TARGET (только для версии Red Brick 4. 0 и выше)
с указанием размера домена.
Редактор Red Brick Physical Object Editor (меню Server/Red Brick Physical
Object) позволяет создавать сегменты (Segment) Red Brick и изменять их
свойства:
• имя сегмента;
• имя файла сегмента, его максимальный размер, начальный размер
(больше 16 кбайт) и размер расширения.
Для каждой таблицы Red Brick можно указать сегменты для хранения
данных и индекса первичного ключа, максимальное количество сегментов
(для версии 5) и максимальное количество строк в сегменте (для Red Brick
версии 5).
Для Teradata ERwin также поддерживает специфические объекты физи-
ческой памяти. В диалоге Teradata Physical Object Editor (меню Server/Tera-
data Physical Object) можно создать базы данных Teradata и определить их
свойства:
• имя владельца базы данных;
• резервированный размер базы данных;
• возможность создания дубликатов таблиц для аварийного восста-
новления;
• размер spool-файлов;
• место для создания журнала (базы данных и таблицы) и его свойства;
• описание базы данных.
В закладке Physical Props диалога Teradata Table Editor можно опреде-
лить параметры аудирования и восстановления после сбоя:
• имя таблицы, которая используется для ведения журнала;
• опцию FALLBACK PROTECTION - создание одновременно основной
и резервной копии таблицы;
• размер пространства, резервируемый для редактируемых данных;
• размер блоков данных.
Закладка Teradata MACRO диалога Teradata Table Editor позволяет соз-
дать шаблоны для хранимых процедур Teradata.
Дата публикования: 2015-10-09; Прочитано: 676 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!
