Заключительные замечания
Обсудим в этом разделе несколько аспектов родовой структуры, в том числе, методы проектирования баз данных, технику реализации и языки запросов. Мы начнем с методов проектирования баз данных – сначала обсуждение будет концентрироваться на "нормальных формах", и затем будет перенесено на методологию проектирования.
В разд. 3 мы определили, что отношение является правильно определенным, если оно удовлетворяет пяти реляционным инвариантам. Кодд и другие авторы предложили несколько нормальных форм как некоторое понятие "хорошего" отношения. Какова связь между правильно определенным отношением и отношением в нормальной форме?
По существу, нормальные формы являются попыткой формализовать понятие "базисного агрегатного объекта" в терминах понятия функциональной зависимости. Эти нормальные формы не предназначены для того, чтобы иметь дело со свойствами обобщения. Если задан агрегатный объект, нормальные формы полезны в решении вопроса, является ли этот объект базисным (т.е. для этого объекта не имеется никаких других объектов, встроенных в него). Однако в настоящее время нормальные формы не позволяют охарактеризовать, что такое агрегатный (или не агрегатный) объект.
С интуитивной точки зрения, агрегатный объект – это нечто, что мы можем именовать существительным (или именным словосочетанием) и, вероятно, рассматривать как единое целое. Требуя, чтобы отношения были именованными, агрегатная структура фиксирует этот аспект агрегатного объекта. В нормальных формах именование не учитывается явным образом, и в результате отношения в нормальной форме могут быть не именуемыми действенным образом (не считая сентенционного описания). Так, например, отношение R на рис. 20 удовлетворяет (мы полагаем) требованиям всех известных из публикаций нормальных форм. Однако это отношение не представляет собой агрегатный объект, поскольку оно, очевидно, не имеет какого-либо имени, удовлетворяющего семантическим критериям правильно определенного объекта.
R (мужчина, стоимость недвижимости, женщина, стоимость недвижимости)
Кортеж принадлежит R, если и только если x обладает какой- либо долей недвижимости стоимостью y, z обладает какой-либо долей недвижимости стоимостью w, и y > w.
(Предполагается, что и мужчины, и женщины, могут обладать несколькими долями недвижимости.)
Рис. 20. Отношение в нормальной форме, которое не является именуемым действенным образом
С другой стороны, хотя агрегатная структура является более сильной попыткой фиксации понятия "агрегатного объекта", она не фиксирует понятия "базисный". Мы полагаем поэтому, что "правильно определенное отношение" и "отношение в нормальной форме" являются взаимно-дополняющими друг друга критериями для использования при проектировании баз данных. В том случае, если были обнаружены правильно определенные отношения, их внутренняя структура зависимостей может быть проверена по критериям нормальных форм. Если правильно определенное отношение не находится в нормальной форме, может быть целесообразной (или не целесообразной) дальнейшая декомпозиция этого отношения.
В работе была предложена методология проектирования баз данных, которая приводит к агрегатным объектам, а затем – к правильно определенным отношениям. Эта методология не рассматривает, однако, декомпозицию в плоскости обобщения (т.е., неявно предполагались одноуровневые родовые иерархии). Тем не менее, она может быть расширена очевидным образом с тем, чтобы рассматривать декомпозицию в обоих плоскостях. Может быть, наиболее выгодно осуществлять декомпозицию в плоскости обобщения прежде, чем проводить декомпозицию в плоскости агрегации. Причина заключается в том, что каждый кластер, вводимый в плоскости обобщения, требует вставки некоторого нового объекта в плоскости агрегации.
Следует теперь сделать несколько комментариев относительно техники реализации реляционных моделей на более низких уровнях. В такой реализации необходимо рассматривать два фактора:
- как представляется структура отношения и
- каким образом поддерживаются реляционные инварианты.
Одно из соображений, принимаемых во внимание при выборе представления структуры, – экономия пространства памяти за счет исключения избыточной информации. Такая информация возникает как в плоскости агрегации, так и в плоскости обобщения. В плоскости агрегации она появляется в результате повторения значений ключа вверх по иерархии. В плоскости обобщения она появляется, когда значения ключевых или неключевых атрибутов повторяются вверх по иерархии. Одним из следствий удовлетворения реляционных инвариантов является обеспечение согласованности всей избыточной информации. Следовательно, при максимально возможном исключении избыточной информации реляционные инварианты будут поддерживаться наиболее эффективным образом.
Предварительные исследования показывают, что реляционные модели могут представляться без какой-либо избыточности в терминах структур наборов DBTG (Database Task Group). Для плоскости агрегации каждая иерархическая ветвь становится отдельным типом набора с отношением более высокого уровня в качестве типа члена и отношением более низкого уровня в качестве типа владельца. Каждый экземпляр набора содержит в качестве членов все кортежи, которые ссылаются на кортеж-владелец. В плоскости обобщения каждая совокупность иерархических ветвей, исходящих из заданного отношения, становится отдельным типом набора. Отношение более высокого уровня представляет тип владельца, а все подчиненные ему отношения – типы членов. Каждый экземпляр набора содержит в качестве членов все образы-потомки данного кортежа-владельца. Большинство реляционных инвариантов, как нам кажется, может поддерживаться с помощью возможностей языка определения данных DBTG. Этот вопрос, однако, еще полностью не решен.
Обсудим, наконец, некоторые вопросы, связанные с языками доступа для реляционных моделей. Когда мы начинали наше исследование обобщения и его представления в реляционных моделях, мы предполагали, что язык запросов высшего порядка был бы существенным для операций над богатой иерархической структурой.
Казалось, что помимо переменных первого порядка, определенных на отношениях первого порядка (т.е. отношений индивидуумов), для оперирования отношениями высших порядков (т.е., отношений отношений и т.д.) были бы необходимы переменные высших порядков.
Однако мы недооценили мощь абстракции. Наша мотивация родовых структур заключалась в обеспечении унифицированной интерпретации всех видов объектов – индивидуальных, агрегатных и родовых. Это означает, что отношения высших порядков структурно идентичны отношениям первого порядка. В результате язык запросов первого порядка оказывается адекватным для всех реляционных моделей, безотносительно к тому, как много уровней обобщения они содержат. По существу, навязывая соответствующую дисциплину структурирования, мы способны эксплуатировать богатство, которое уже подразумевалось в первоначальной работе Кодда.
Несмотря на тот факт, что язык первого порядка может быть адекватен для запросов, существуют серьезные причины разработки примитивов высших порядков для программирования приложений. Рассмотрим следующий запрос, связанный с реляционной моделью, представленной на :
"Выяснить, какой тип имеет служащий E5, а затем извлечь его запись из множества записей этого типа служащих."
Этот запрос можно удобно выразить в двух частях, как показано ниже:
Часть 1: R < RESTRICT (employee to E# = E5); S < PROJECT (R on TN); RETRIEVE S;
Часть 2 (в предположении, что ответ на Часть 1 – "trucker"): T < RESTRICT (trucker to E# = E5); RETRIEVE T;
Первая часть возвращает тип служащего E5, например, "trucker", а вторая часть извлекает запись E5 из множества записей типа "trucker". В этом случае пользователь должен формулировать вторую часть, исходя из информации, полученной в первой части.
Если бы этот запрос реализовался как прикладная программа, пользователя можно было бы "заменить" приведенным ниже оператором case:
READ X; R < RESTRICT (employee to E# = X); S < PROJECT (R on TN); T < case S of
trucker: RESTRICT (trucker to E# = X); secretary: RESTRICT (secretary to E# = X); engineer: RESTRICT (engineer: to E# = X) end
RETRIEVE T;
Проблема с использованием оператора case состоит в том, программа становится зависимой от родовых компонентов "employee" в один из моментов времени. Если нанимают служащего нового типа (скажем, "cторожа" (guard)), то программа не будет работать, когда будет введен номер служащего-сторожа.
Эта "зависимость от времени" может быть устранена с помощью оператора более высокого порядка, который мы назовем SPECIFY. При заданном имени отношения оператор SPECIFY будет возвращать отношение с таким именем. Теперь можно переписать программу так, как показано ниже.
READ X; R < RESTRICT (employee to E# = X); S < PROJECT (R on TN); T < SPECIFY S; U < RESTRICT (T to X); RETRIEVE U;
Новая программа независима от родовых компонентов "employee" в любой момент времени.
Введение примитивов более высокого порядка может, таким образом, повысить стабильность программ при эволюционировании базы данных в соответствии с реальным миром. Не ясно, какие другие операторы высших порядков полезны наряду с SPECIFY. Насколько нам известно, эти аспекты программирования приложений должны еще быть исследованы.
