Создание физической модели хранилища данных

Моделирование объектов физической модели хранилища данных

Описание учебного примера

Рассмотрим в качестве примера логическую модель ХД типа "звезда" на рис. 11.2 и построим на ее основе физическую модель ХД.

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

Логическая модель ХД, приведенная на рисунке, была разработана для анализа продаж компании в разрезах товаров, продавцов, покупателей, времени продаж. Она включает в себя четыре сущности для измерений: "Время" (Time), "Покупатель" (Customer), "Товар" (Product), "Продавец" (Employee) – и одну сущность для фактов "Продажи" (Sale).

Как видно из приведенной схемы, для атрибутов определены домены "Целое число", "Десятичное число", "Текст" размером в 20 и 40 символов.

Описание атрибутов модели приведено в табл. 11.2.

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

• Разработка физической модели ХД:
  • определение базовых таблиц БД;
  • определение колонок в таблицах ;
  • определение типов данных для колонок;
  • назначение первичных ключей таблицам ;
  • задание ограничений NOT NULL на значения колонок;
  • создание связей между таблицами.
• Разработка скрипта создания ХД:
  • формирование команд CREATE TABLE для таблиц ХД;
  • определение ограничений на колонки таблиц ХД;
  • формирование дополнительных индексов командой CREATE INDEX.

Моделирование таблиц хранилища данных

Определение базовых таблиц

Как указывалось выше, первый шаг в построении физической модели ХД есть идентификация таблиц БД. При решении этой задачи проектировщик ХД имеет на входе отношения логической модели данных ХД, представляющие сущности предметной области, а на выходе этапа моделирования должен иметь определения таблиц, их колонок, ключей и индексов и т.д.

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

Для нашего учебного примера создадим пять таблиц: четыре таблицы измерений "Время" (Time), "Покупатель" (Customer), "Товар" (Product), "Продавец" (Employee) и одну таблицу фактов "Продажи" (Sale). Имена таблиц будут соответствовать именам сущностей логической модели ХД ( рис. 11.3).

Рис. 11.3. Создание таблиц физической модели хранилища данных

Когда проектировщик заканчивает обработку всех отношений логической модели данных, он должен еще раз проверить, соответствует ли число базовых таблиц числу отношений логической модели данных (т.е. не меньше, чем число сущностей предметной области). Таким образом, при создании базовых таблиц проектировщик придерживается принципа: каждому отношению логической модели данных — по базовой таблице.

Определение колонок в таблицах

Следующим шагом проектировщика ХД является определение колонок для базовых таблиц. Колонки таблицы должны представлять атрибуты отношений логической модели реляционной ХД. Эти атрибуты необходимо преобразовать в спецификации колонок в команде CREATE TABLE. Спецификация колонки таблицы имеет следующий синтаксис: имя колонки, тип данных для значений, сохраняемых в колонке, список ограничений.

Сначала рассмотрим задачу добавления колонок. Колонка должна иметь имя. Имена атрибутов соответствующих отношений логической модели преобразуются в имена колонок в соответствии с правилами именования объектов, принятых в конкретной СУБД. Обычно, как указывалось выше, это ограничение на длину имени и применение в имени специальных символов. Например, в некоторых СУБД допускается использовать знак доллара в имени, однако этот знак обычно не распознается в командах выборки данных – SELECT.

увеличить изображение
Рис. 11.4. Определение имен колонок таблиц физической модели хранилища данных

Имеется еще одна проблема в именовании колонок – имена колонок должны интерпретироваться пользователем однозначно. Например, если проектировщик назначит для фамилии сотрудника короткое имя LN, то, наверное, потребуется комментарий, в котором необходимо указать, что это фамилия, а не линия (например, в смысле "линия производства"). Если невозможно использовать по каким-то причинам длинные имена полей, то следует использовать словарь данных для интерпретации введенных аббревиатур.

Для нашего учебного примера решение этой задачи сводится к перенесению атрибутов сущностей в поля соответствующих таблиц БД. Заметим, что атрибуты, претендующие в кандидаты на внешние ключи, не переносятся. На рис. 11.4 показан результат проделанной работы.

Заметим, что для соблюдения принципа уникальности имен полей в рамках модели при определении полей на основе имен атрибутов сущностей мы изменили некоторые имена. Так, имя атрибута "Адрес" (Address) сущности "Продавцы" (Employee) в соответствующей таблице "Продавцы" (Employee) физической модели стало "Адрес продавца" (Empl_Address). Аналогично имя атрибута "Адрес" (Address) сущности "Покупатели" (Customer) в соответствующей таблицы "Покупатели" (Customer) физической модели стало "Адрес покупателя" (Cust_Address).

Определение типов данных для колонок

После идентификации колонок необходимо задать их тип в соответствии с допустимыми для данной СУБД типами данных. Эта задача упрощается, если в отношениях логической модели определены домены атрибутов. Некоторые из доменов могут быть определены уже в терминах СУБД. Для таких атрибутов практически ничего делать не нужно. Определение домена в терминах типа данных СУБД нужно просто перенести в спецификацию колонки. Возможно, проектировщику будет нужно уточнить второстепенные параметры типа. Например, если задан домен как DEC(9,2), а из контекста предметной области следует, что в этой колонке будет накапливаться итоговая сумма расходов за год, то, может быть, целесообразно определить тип как DEC(15,2), чтобы избежать возможного переполнения при работе приложений базы данных.

Если домен определен не в терминах СУБД, проектировщик базы данных должен преобразовать его в подходящий тип данных. При выполнении таких преобразований следует учитывать ряд факторов.

• Следует уточнить, как СУБД физически хранит данные того или иного предопределенного типа, и затем уточнить интервалы изменения значений колонок. Например, если тип переменной — varchar(3), и она содержит код, значение которого изменяется в интервале от '10A' до '99Z', то целесообразно с точки зрения хранения изменить тип этой переменной на char(3). Это объясняется тем, что тип varchar при физическом хранении занимает на байт-два больше, чем тип char при одной и той же объявленной длине.
• Для числовых значений фиксированной длины предпочтительнее использовать тип DEC. Он обрабатывается процессором быстрее, чем тип FLOAT. Исключение составляют данные для научных расчетов, где представление чисел в экспоненциальной форме бывает необходимо.
• Используйте INT и SMALLINT исключительно для счетчиков.
• Избегайте использовать тип CHAR для представления числовых данных. Во-первых, может потребоваться дополнительная проверка, а во-вторых, могут возникнуть проблемы при сортировке таких колонок, поскольку число, заданное строкой '11' будет находиться выше, чем число, заданной строкой '9', при упорядочивании по возрастанию.
• Используйте типы DATE и TIME только для хранения хронологических данных.
• Используйте тип DATETIME исключительно для целей управления данными.

увеличить изображение
Рис. 11.5. Определение типов данных для колонок таблиц физической модели хранилища данных

В нашем учебном примере для всех атрибутов задан домен. Для суррогатных первичных идентификаторов сущностей это числовое значение. Учитывая, что ХД будет хранить большие объемы данных, для представления таких атрибутов в БД целесообразно выбрать тип данных bigint, а для остальных атрибутов — тип данных integer. Домен "Текст" можно представить типом данных varchar(n), для представления десятичных чисел использовать тип данных numeric (p, s ).

Результат определения типов колонок таблиц физической модели ХД показан на рис. 11.5.