12.6. Краткий анализ

В этом разделе кратко рассматриваются некоторые другие аспекты модели типа объ­ект/отношение. Большая часть излагаемого здесь материала взята из другой работы автора [12.7], в которой эта тема обсуждается подробнее.

Модель объект/отношение как основа реляционной модели

Рассмотрим подход на основе модели объект/отношение с несколько иной точки зре­ния. Вероятно, идеи, основанные на таком подходе или близкие к ним, с точки зрения Кодда, составляли неформальную основу при создании формальной реляционной мо­дели. Как уже объяснялось выше в этой главе, общий подход к семантическому моде­лированию включает четыре больших этапа; цель каждого из них можно кратко сформулировать следующим образом:

1. Идентифицировать полезные семантические концепции.

2. Вывести формальные объекты.

3. Вывести формальные правила целостности.

4. Вывести формальные операторы.

Обратите внимание, что эти четыре этапа также применимы для проектирова­ния базовой реляционной модели (и для любой формальной модели данных), а не только для "расширенных" моделей типа объект/отношение. Иначе говоря, для того чтобы создать (формальную) базовую реляционную модель, Кодд прежде всего должен был разработать некоторые (неформальные) "полезные семантиче­ские концепции", основанные либо на идеях модели объект/отношение, либо на подобных им концепциях. Действительно, работы Кодда подтверждают это, по­скольку в его первой статье [4.2], посвященной реляционной модели, приведены следующие строки:

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

Здесь Кодд в ясной форме предлагает, чтобы отношения использовались для мо­делирования и "объектов", и "зависимостей". Но самое главное заключается в том, что отношения являются формальными объектами, а реляционная система — фор­мальной системой. Ценность научного вклада Кодда состоит в том, что он нашел удачную формальную модель для некоторых аспектов реального мира.

Наоборот, модель объект/отношение не является (или, по крайней мере, не в первую очередь является) формальной моделью. Действительно, она преимущественно состоит из набора неформальных концепций, соответствующих (только) первому из четырех приведенных выше этапов. (Более того, ее формальные аспекты на самом деле не очень значительно отличаются от соответствующих аспектов основной реляционной модели; обсуждение этого вопроса будет продолжено далее.) Для проектирования базы данных, несомненно, полезно иметь в своем распоряжении (помимо прочих) "непробиваемые" концепции, представленные на этапе 1. Однако немаловажным остается тот факт, что проектирование базы данных не может быть выполнено без формальных объектов и правил, представленных на этапах 2 и 3, а многие другие задачи вовсе не могут быть выполнены без использования формальных операторов этапа 4.

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

Является ли модель объект/отношение моделью данных

Исходя из изложенного, не совсем ясно, является ли модель объект/отношение на самом деле моделью данных, по крайней мере, в предложенном в этой книге смысле (т.е. как формальная система, включающая структурные аспекты, аспек­ты целостности и манипулирования). Конечно, термин "моделирование типа объ­ект/отношение" обычно используется для обозначения процесса выбора (только) структуры базы данных, хотя выше в этой главе рассматривались некоторые ас­пекты целостности. Однако при более внимательном чтении оригинальной статьи Чена можно предположить, что модель объект/отношение действительно являет­ся моделью данных, но такой, которая представляет собой лишь тонкий слой на вершине базовой реляционной модели (и конечно, не может заменить реляцион­ную модель, как хотелось бы некоторым разработчикам). Это утверждение мож­но обосновать приведенными ниже доводами.

• Прежде всего, фундаментальный элемент данных для модели объект/отношение, т.е. фундаментальный формальный элемент, который является противоположно­стью неформальным элементам — "объекту", "зависимости" и т.д., является от­ношение степени п.

• Операторы модели объект/отношение в основном являются операторами реляци­онной алгебры. (Действительно, работу [12.3] нельзя назвать очень ясной в этом отношении, но в ней предлагается менее мощное по сравнению с реляционной ал­геброй множество операторов, среди которых, например, не существует объеди­нения и явно заданного соединения.)

• Именно в вопросах целостности эти два подхода в некоторой степени отличаются друг от друга: модель объект/отношение содержит набор встроенных правил це­лостности, соответствующих некоторым, но не всем правилам внешнего ключа, описанным в главе 5 этой книги. Таким образом, там, где для "чистой" реляцион­ной системы потребовалось бы явно сформулировать некоторые правила для внешних ключей, для модели объект/отношение достаточно было указать, что данное отношение имеет некоторый тип, и соответствующие правила для внешних ключей были бы задействованы.

Объекты по сравнению с отношениями

В этой книге уже несколько раз отмечалось, что "отношения" лучше всего рассмат­ривать всего лишь как определенного рода объекты. И наоборот, обязательным усло­вием модели объект/отношение является то, что эти два понятия должны каким-то образом различаться. По мнению автора, любой подход, в котором преследуется та­кое разделение, обладает серьезными недостатками, поскольку, как уже отмечалось выше в этой главе, один и тот же элемент может совершенно справедливо рассмат­риваться как объект одними пользователями и как отношение — другими. В этой свя­зи можно рассмотреть следующий пример заключения брака.

• С одной стороны, браком называется некоторая связь между двумя людьми. В ка­честве примера можно привести запрос: "С кем вступила в брак Элизабет Тейлор в 1975 году?"

• С другой стороны, брак является своего рода объектом. В качестве примера мож­но привести следующий запрос: "Сколько браков было заключено в этой церкви с апреля?"

Если в методике проектирования базы данных предполагается наличие некоторых различий между "объектом и отношением", то в лучшем случае эти две интерпрета­ции будут рассматриваться асимметрично (т.е. запросы для "объектов" и запросы для "отношений" буду выглядеть совершенно по-разному). А в худшем случае одна ин­терпретация вовсе не будет поддерживаться (т.е. один из классов запроса будет не­возможно сформулировать).

В качестве еще одной иллюстрации рассмотрим следующее утверждение о модели объект/отношение из [12.10]:

"Обычно сначала следует представить некоторые отношения в виде атрибутов [которые в данном случае означают внешние ключи] для концептуальной схемы проектирования, а затем преобразовать эти атрибуты в отношения по мере даль­нейшего развития и более глубокого понимания процесса проектирования".

Но что произойдет, если атрибут станет внешним ключом еще позже, т.е. если база данных будет изменена после того, как она использовалась в течение некоторого времени? Если эту идею логически развивать, то можно прийти к выводу, что макет базы данных должен содержать только отношения и совсем никаких атрибутов!