7. Примеры преобразования: Консультационная Служба
В лабораторных работах, посвященных концептуальному моделированию, мы создали концептуальную модель счета за выполнение проекта для Консультационной Службы. Эта модель представлена на рис. 12. Применяя выше изложенные принципы, мы преобразуем эту модель в реляционную схему.
Рис. 12. Модель данных для описания счета за выполнение проекта
Реляционные таблицы для объектных множеств PROJECT (ПРОЕКТ) и CLIENT таковы:
CLIENT (NAME-CLIENT, ADDRESS-CLIENT),
PROJECT (PROJECT-#, NAME-CLIENT, PROJECT-TITLE, TOTAL-CHANGE, INVOICE-#, INVOICE-DATE).
Внешние ключи:
NAME-CLIENT ссылается на CLIENT.
Атрибут PROJECT-# (НОМЕР ПРОЕКТА) был добавлен, так как нам необходим ключ для таблицы PROJECT. PROJECT-TITLE (НАЗВАНИЕ ПРОЕКТА) не определяет однозначно проект. INVOICE-# (№-СЧЕТА) однозначен, но он не является подходящим ключом для таблицы, описывающей проекты. Для ясности мы также изменили некоторые имена атрибутов, например, NAME-CLIENT или PROJECT-TITLE. Изменение NAME на NAME-CLIENT является существенным, так как этот атрибут является внешним ключом в таблице PROJECT.
Кроме этих двух таблиц, нам нужны таблицы для объектов CHANGE (ПЛАТА) и SERVICE (ПЛАТА-ЗА-У СЛУГИ):
CHANGE (CHANGE-#, PROJECT-#, AMOUNT, DESCRIPTION)
Внешний ключ: PROJECT-# ссылается на PROJECT
SERVICE (CHANGE-#, PROJECT-#, CONSULTANT)
Внешний ключ: CHANGE-#, PROJECT-# ссылаются на CHANGE
Преобразуя объектное множество CHANGE в реляционную таблицу, мы должны решить, что будет ее ключом. В нашем случае мы приняли решение, что проект, за который назначена плата, частично определяет ее. Таким образом, мы использовали PROJECT-# в качестве части ключа. В качестве второй части ключа мы добавили CHANGE-# (НОМЕР-ПЛАТЫ). Это означает, что разные платы могут иметь одинаковые номера, если относятся к разным проектам.
Объект SERVICE является конкретизацией объектного множества CHANGE, поэтому реляционная таблица SERVICE должна иметь тот же ключ, что и реляционная таблица CHANGE. Разумеется, это означает также, что этот составной ключ также является внешним ключом, указывающим на таблицу CHANGE. Кроме того, таблица SERVICE имеет атрибут CONSULTANT (КОНСУЛЬТАНТ), идентифицирующий консультанта, который выполнял работу. Хотя объект SUPPLY-CHANGE (ПЛАТА-ЗА-МАТЕРИАЛЫ) также является конкретизацией объектного множества CHANGE, для него не стоит создавать отдельную таблицу, так как он не имеет своих собственных атрибутов. Вся информация о затраченных материалах может быть найдена в таблице CHANGE.
На рис. 13 представлена модель данных, созданная для счетов за проекты консультационной фирмы. Сейчас мы преобразуем ее в реляционную модель. Объектные множества CUSTOMER и PROJECT преобразуются как и раньше:
CLIENT (CLIENT-NAME, CLIENT-ADDRESS)
PROJECT (PROJECT-#, CLIENT-NAME, PROJECT-TITLE, TOTAL-CHANGE, INVOICE-#, INVOICE-DATE)
Внешние ключи: CLIENT-NAME ссылается на CUSTOMER
Объектное множество ДРУГИЕ-РАСХОДЫ в этой модели соответствует объектному множеству CHANGE предыдущей модели:
CHANGE (CHANGE-#, PROJECT-#, AMOUNT, DESCRIPTION)
Внешний ключ: PROJECT-#t ссылается на PROJECT
Нам также требуется таблица для объекта CONSULTANT:
CONSULTANT (CONSULTANT-NAME, RATE)
Рис. 13. Расширенная модель данных для счета
Наконец, нам необходимо представить отношение, заключенное в большой прямоугольник. Поскольку отношение ENGAGED-IN (ЗАНЯТ-В) не имеет собственных атрибутов, мы можем включить его в таблицу, представляющую отношение ON (ДЛЯ). Эта таблица эквивалентна трехстороннему отношению, поэтому ее ключ будет состоять из трех атрибутов. Она также содержит два неключевых атрибута HOURS (ЧАСЫ) и AMOUNT (СУММА):
ENGAGED-IN-ACTIVITY-ON (CONSULTANT-NAME, ACTIVITY, PROJECT-#,
HOURS, AMOUNT).
Внешние ключи:
CONSULTANT-NAME ссылается на CONSULTANT
PROJECT-# ссылается на PROJECT
Поскольку название ON недостаточно хорошо описывает смысл отношения, мы дали таблице новое имя, которое сочли более осмысленным.
Хотя процесс преобразования концептуальной модели в реляционную является прямым и механическим, он все же требует некоторого применения интеллекта. Мы продемонстрировали это в предыдущих двух примерах, выбирая разные ключи и по мере необходимости меняя имена атрибутов и таблиц. Тем не менее, процесс довольно прост, и все полученные в результате таблицы имеют четвертую нормальную форму.