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

Назначение первичных ключей таблицам

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

Задание колонки как первичного ключа в контексте многих СУБД, в том числе и семейства MS SQL Server, считается ограничением на значение колонки (см. далее настоящую лекцию).

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

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

Задание ограничений NOT NULL на значения колонок

При определении спецификаций колонок таблиц проектировщик должен рассмотреть ограничения, которые могут быть наложены на значения колонок. В реляционных СУБД предусмотрено достаточно много подобных ограничений. Здесь мы остановимся на одном из главных – на обязательности присутствия значения в колонке. Такое ограничение на значения колонки называется NOT NULL-ограничением.

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

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

При назначении NULL-значений колонкам проектировщику необходимо принимать во внимание следующие факторы.

• Колонки, являющиеся частью составного первичного ключа, должны иметь всегда ограничение NOT NULL, т.к. согласно реляционной теории значения колонок первичного ключа должны быть определены и уникальны для каждого кортежа.
• Внешние ключи должны также определяться как NOT NULL, и поскольку дочерняя таблица зависит от родительской, внешний ключ родительской не может иметь NULL-значения. Это следует из того, что существование строки дочерней таблицы без соответствующей строки родительской таблицы нарушает правило зависимости связи (о внешних ключах, родительских и дочерних таблицах см. далее).
• Только внешние ключи для таблицы с опциональной связью могут рассматриваться как кандидаты на наличие NULL-значений, чтобы показать, что для данной комбинации родительской и дочерних строк в этих таблицах связи нет.
• Внешние ключи с правилом удаления SET NULL должны определяться со спецификацией NULL.
• Используйте спецификацию NOT NULL WITH DEFAULT для колонок с типами данных DATE или TIME, чтобы сохранять текущие даты и текущее время автоматически.
• Разрешайте использовать NULL-значения только для тех колонок, которые действительно могут иметь неопределенные значения.
• Используйте NOT NULL WITH DEFAULT для всех колонок, которые не подпадают под перечисленные выше правила.

Для нашего учебного примера все колонки таблиц физической модели ХД, может быть, за исключением адресов, должны иметь ограничение NOT NULL ( рис. 11.6).

увеличить изображение
Рис. 11.6. Задание ограничений NOT NULL на значения колонок

Создание связей между таблицами

Следующим шагом в моделировании физической модели ХД является установление взаимосвязи между таблицами модели ХД.

Таблицы измерения и таблица фактов в многомерной модели данных находятся в отношении "родитель-потомок". Первичный и соответствующий ему внешний ключ позволяют реализовать отношение "родитель-потомок" (parent/child relationship) между таблицами реляционной БД. Они отражают взаимосвязь между объектами предметной области (представленными кортежами таблиц ) через значения некоторых их атрибутов по принципу иерархического подчинения, когда объект-родитель определяет существование объектов-потомков. Сами объекты-потомки могут также выступать в качестве родителей для других объектов (descendents).

Таблица реляционной базы данных, содержащая первичный ключ, называется таблицей-родителем (parent table), или родительской таблицей, а таблица, содержащая соответствующий первичному ключу внешний ключ, — таблицей-потомком (child table), или дочерней таблицей. Таблица измерений "Товары" (Product) учебного примера является таблицей-родителем для таблицы фактов "Продажи" (Sale).

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

Отношения "родитель-потомок" между двумя таблицами отражают взаимосвязь по включению на доменах соответствующих атрибутов.

Установив связь "родитель-потомок" между таблицами измерений и таблицей фактов нашего учебного примера, получим физическую модель ХД ( рис. 11.7)

увеличить изображение
Рис. 11.7. Задание ограничений NOT NULL на значения колонок

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

В нашем примере таблица фактов имеет уникальный суррогатный ключ "Идентификатор продажи" ( Sale_ID ), поэтому внешние ключи, реализующие отношение "родитель-потомок" между таблицами измерений и таблицей фактов, не обязательно включать в составной первичный ключ таблицы фактов. Любая строка таблицы фактов однозначно идентифицируется уже назначенным первичным ключом.

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