Опубликован: 20.12.2010 | Уровень: специалист | Доступ: свободно
Лекция 12:

Создание модели хранилища данных на основе корпоративной модели данных

Использование CASE-инструментов для создания многомерной модели на основе корпоративной модели данных

Корпоративная модель данных учебного примера

Мы будем рассматривать применение CASE-средств на примере продукта PowerDesigner компании Sybase для моделирования ХД на основе СУБД MS SQL Server компании Microsoft.

Допустим, что руководство компании по розничной торговле издательской продукцией приняло решение о реализации ХД (а именно киоска данных) для анализа продаж изданий и анализа вклада авторов в общий доход компании. К моменту принятия решения о разработке киоска данных у ИТ-подразделения компании существовала корпоративная модель данных и операционная система обработки данных на СУБД MS SQL Server.

Логическая схема корпоративной модели издательской компании приведена на рис. 16.15.

Логическая схема корпоративной модели издательской компании

увеличить изображение
Рис. 16.15. Логическая схема корпоративной модели издательской компании

Корпоративная модель данных компании документирована. Все сущности, атрибуты сущностей и домены описаны. Пример описания сущности "Автор" ( Autor ) приведен в табл. 16.1.

Таблица 16.1. Сущность "Автор" (Autor)
Имя атрибута Код атрибута Тип данных Домен Ключ
1 Author ID (Идентификатор автора) AU_ID A12 Алфавитно-цифровой Да, NOT NULL
2 Author Last Name (Фамилия) AU_LNAME VA40 Алфавитный NOT NULL
3 Author First Name (Имя) AU_FNAME VA40 Алфавитный NOT NULL
4 Author Biography (Биография автора) AUTHOR BIOGRAPHY TXT Текст
5 Author Advance (Доплаты авторам) AU_ADVANCE MN8,2 Десятичное число
6 Author Address (Адрес автора) AU_ADDRESS VA80 Текст
7 City (Населенный пункт) CITY VA20 Алфавитный
8 State (Область) STATE VA80 Алфавитный
9 Postal Code (Почтовый индекс) POSTALCODE N Целочисленный
10 Author Phone Number (Телефон автора) AU_PHONE A12 Алфавитно-цифровой NOT NULL

Идентифицируем бизнес-процессы предметной области киоска данных по представленной на рис. 16.15 модели "сущность-связь" и применим алгоритм преобразования корпоративной модели, описанный в предыдущих разделах настоящей лекции.

Для проектирования многомерной модели нам потребуется еще одни документ – физическая модель операционной системы обработки данных компании, которая приведена на рис. 16.16.

Она нам нужна для правильного выбора наименований полей и их типов при перенесении в многомерную модель данных.

Физическая схема корпоративной модели

увеличить изображение
Рис. 16.16. Физическая схема корпоративной модели

Идентификация бизнес-процессов компании и отбор данных

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

Для бизнес-процесса продажи изданий через магазины (бизнес-процесс 1) мы имеем следующие сущности корпоративной модели данных:

  • сущность-супертип "Наименование изданий" ( Тitle ) с подчиненными ей подтипами "Периодические издания" ( Periodical ) и "Непериодические издания" ( Nonperiodical );
  • сущность "Продажи" ( Sale );
  • сущность "Магазин" ( Store ).

Для бизнес-процесса продажи изданий конкретного автора (бизнес-процесс 2) мы имеем следующие сущности корпоративной модели данных:

  • сущность "Автор" ( Author );
  • сущность "Продажи" ( Sale );
  • сущность "Издание Автор" ( TitleAuthor ).

Применение алгоритма преобразования корпоративной модели в многомерную модель данных разберем на примере бизнес-процесса 1. Преобразование для бизнес-процесса 2 выполняется аналогично.

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

Хорошим правилом будет разбить выделенные сущности на два класса: транзакционные сущности, которые фиксируют бизнес-операции, и нетранзакционные сущности, которые хранят описания бизнес-операций и бизнес-процессов. Первые претендуют быть прототипами таблиц фактов, а вторые – таблиц измерений многомерной модели.

Для бизнес-процесса 1 такое разбиение представлено в табл. 11.2.

Таблица 16.2. Разбиение сущностей на типы
Транзакционные сущности Нетранзакционные сущности
"Продажи" (Sale) - описывает бизнес-операцию продажи издания "Магазин" (Store) описывает магазин как объект бизнес-процесса, через который осуществляется продажа
"Наименование изданий" (Тitle) с подчиненными ей "Периодические издания" (Periodical) и "Непериодические издания" (Nonperiodical) описывает издания, которые продаются в магазинах

Таким образом, для бизнес-процесса 1 имеем таблицу фактов "Продажи" (Sale) и две таблицы измерений "Магазин" (Store) и "Наименование изданий" (Тitle), при этом обратим внимание на то, что в физической модели была выполнена денормализация сущности "Наименование изданий" включением в нее атрибутов подчиненных сущностей "Периодические издания" ( Periodical ) и "Непериодические издания" ( Nonperiodical ).

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

Таблица 16.3. Отобранные атрибуты
Таблица модели ХД Таблица внешней БД Отобранные атрибуты
Sale Sale SALE_ID (Идентификатор продажи)
STOR_ID (Идентификатор магазина)
TITLE_ISBN (ISBN издания)
SALE_DATE (Дата продажи)
SALE_AMOUNT (Сумма)
SALE_TERMS (Условия продажи)
SALE_QTY (Количество)
Store Store STOR_ID (Идентификатор магазина)
STOR_NAME (Название магазина)
CITY (Населенный пункт)
STATE (Область)
POSTALCODE (Почтовый индекс)
STOR_ADDRESS (Адрес магазина)
Тitle Тitle TITLE_ISBN (ISBN издания)
PUB_ID (Идентификатор издателя)
TITLE_TEXT (Название издания)
TITLE_TYPE (Тип издания)
TITLE_PRICE (Цена издания)
TITLE_NOTES (Признак примечаний)
TITLE_PUBDATE (Дата выпуска издания)
PERIODICAL (Признак периодичности издания)
PER_FREQUENCY (Частота выпуска издания)
NONP_COLLECTION (Непериодическое издание)

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

Рассмотрим теперь взаимосвязи между данными (четвертый этап преобразования корпоративной модели данных ). В нашем случае транзакционной таблицы фактов преобразование связей не требуется. Таблица фактов фиксирует историю ежедневных продаж изданий в магазинах.

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

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

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

Секционирование таблиц фактов будет рассмотрено далее, после построения многомерной модели.

Рассмотрим использование алгоритма преобразования корпоративной модели данных компании при помощи CASE-средства PowerDesigner компании Sybase.

Создание многомерной модели данных в PowerDesigner

Сначала мы создадим многомерную модель киоска данных для анализа продаж изданий.

Для этого запустим CASE-инструментарий PowerDesigner, выберем функцию " Создать новую физическую модель данных " (Пункты меню File \to New ). В появившемся на экране диалоговом окне " New " выберем в списке "Тип модели" ( Model type ) элемент "Физическая модель данных" ( Physical Data Model ), из выпадающего списка СУБД ( DBMS ) выберем MS SQL Server, а из списка "Первая диаграмма" ( First Diagram ) выберем "Диаграмма физической модели" ( Physical Diagram ) и нажмем на кнопку " OK " ( рис. 16.17).

Создание многомерной модели: выбор СУБД

Рис. 16.17. Создание многомерной модели: выбор СУБД

Далее создадим таблицы, которые будут таблицей фактов и двумя таблицами измерений, используя палитру инструментов ( Palette ). Чтобы создать таблицу, необходимо навести курсор мыши на пиктограмму таблицы на палитре инструментов, щелкнуть по пиктограмме левой кнопкой мыши, перенести курсор на рабочее пространство, еще раз щелкнуть левой кнопкой мыши ( рис. 16.18) и выбрать на палитре инструментов пиктограмму указателя, чтобы перейти к выполнению других функций.

Создание многомерной модели: создание таблиц модели

Рис. 16.18. Создание многомерной модели: создание таблиц модели

Теперь перенесем данные из таблиц корпоративной модели данных в объекты многомерной модели данных (т.е. выполним шестой этап алгоритма преобразования корпоративной модели данных ).

Владислав Нагорный
Владислав Нагорный

Подскажите, пожалуйста, планируете ли вы возобновление программ высшего образования? Если да, есть ли какие-то примерные сроки?

Спасибо!

Лариса Парфенова
Лариса Парфенова

1) Можно ли экстерном получить второе высшее образование "Программная инженерия" ?

2) Трудоустраиваете ли Вы выпускников?

3) Можно ли с Вашим дипломом поступить в аспирантуру?