    Глава 12 

    Модель типа объект/отношение 

    12.1. Введение 

    Основной предмет обсуждения этой главы, а именно модель типа 
объект/отношение, по-видимому, является наилучшим примером класса моделей 
данных, которые называются "расширенными" или семантическими моделями. 
Семантическое моделирование было предметом интенсивных исследований в конце 
1970-х и начале 1980-х годов, причем основным побудительным мотивом таких 
исследований (и формулировки проблемы, которую исследователи пытались 
разрешить) был следующий факт. Дело в том, что системы управления базами 
данных (реляционные или какие-либо другие) обладают весьма ограниченными 
сведениями о смысловом значении данных, хранящихся в некоторой базе данных. 
Обычно они "понимают" некоторые простые ограничения целостности, наложенные на 
некоторые простые атомарные значения (при этом всякая более сложная 
интерпретация возлагается на пользователя). Однако было бы замечательно, если 
бы системы могли чуть больше "понимать" и несколько разумнее отвечать на 
запросы пользователя, а также поддерживать более слож ные (т.е. более 
высокоуровневые) интерфейсы пользователя. Например, было бы прекрасно, если бы 
язык SQL мог "понимать", что вес товара и количество поставок являются хотя и 
числовыми, но все же семантически разными величинами. При этом необходимо, 
чтобы соединение товаров и поставок на основе соответствия веса товара и 
количества поставок могло быть подвергнуто сомнению, если не отвергнуто совсем. 
    Конечно, понятие доменов в значительной степени относится к приведенному 
выше примеру, который служит прекрасной иллюстрацией того, что существующие 
модели данных не совсем избавлены ото всех семантических аспектов. Например, 
домены, потенциальные ключи и внешние ключи являются семантическими аспектами 
существующей реляционной. В качестве другого способа реализации семантики были 
разработаны различные "расширенные" модели, которые несут большую смысловую 
нагрузку, чем предложенные ранее модели. Перефразировав Кодда [12.5], можно 
сказать, что задача извлечения смыслового значения данных может выполняться 
бесконечно и углубление понимания этой проблемы будет сопровождаться 
постепенным прогрессом в этом направлении. Термин "семантическая модель", 
который часто используется по отношению к той или иной "расширенной" модели, в 
данном случае не совсем подходящий, поскольку предполагает, что модель 
построена таким образом, чтобы выявить всю семантику заданной ситуации. С 
другой стороны, понят ие "семантическое моделирование" является довольно 
удачным названием целой области исследований, посвященных способам 
представления смыслового значения. В данной главе представлено краткое 
введение в некоторые базовые идеи этой области исследований, а затем более 
подробно описан подход на основе модели типа объект/отношение. 
    Замечание. Семантическое моделирование (особенно в тех случаях, когда 
исследования выполняются в контексте некоторого макета базы данных для 
некоторого особого предприятия или приложения — подробнее это будет описано 
ниже) имеет также несколько других названий: например, "моделирование данных", 
"моделирование типа объект/отношение" и "объектное моделирование". Здесь по 
некоторым причинам предпочтение отдается термину "семантическое моделирование". 

    Глава 12. Модель типа объект/отношение 331 

    •   Термин "моделирование данных" не подходит, поскольку, во-первых, он 
перекликается с уже определенным ранее термином "модель данных", который 
обозначает формальную систему, состоящую из объектов, правил целостности и 
операторов, а во-вторых, такое название будет способствовать закреплению 
популярного заблуждения (см., например, [4,12]) о том, что модель данных (в 
приведенном выше смысле) включает только структуру данных. 
    •  Также неудачным является термин "моделирование типа объект/отношение", 
поскольку в нем подразумевается существование только одного подхода к данной 
проблеме, тогда как на практике возможно несколько различных подходов. Тем не 
менее, термин "моделирование типа объект/отношение" хорошо известен, весьма 
популярен и принят в широком кругу специалистов. 
    •  Относительно термина "объектное моделирование" нет никаких существенных 
возражений за исключением того, что он кажется более специализированным по 
сравнению с термином "семантическое моделирование" и предполагает некоторое 
смысловое ударение, которое не совсем подходит в данном случае. 
    Возвращаясь к главной теме нашего обсуждения, следует выделить причину 
включения данного материала в книгу. Идеи семантического моделирования могут 
быть полезны при систематическом проектировании базы данных даже при 
отсутствии непосредственной поддержки этих идей в СУБД. Идеи исходной 
реляционной модели использовались в качестве примитивного вспомогательного 
средства при проектировании макета базы данных задолго до появления любых 
коммерческих воплощений этой модели. Точно также идеи некоторой данной 
"расширенной" модели могут быть полезны в качестве вспомогательного средства 
при проектировании макета базы данных, несмотря на то что никаких коммерческих 
воплощений этих идей еще не существует. Действительно, было бы справедливо 
отметить, что на момент написания этой книги основное влияние идеи 
семантического моделирования оказали на проектирование баз данных, поскольку 
было предложено несколько технологий проектирования, основанных на том или 
ином семантическом подходе. Поэтому в данн ой главе акцент будет сделан на 
приложении идей семантического моделирования к задаче проектирования базы данных. 
    Замечание. Методологии проектирования, основанные на идеях семантического 
моделирования, часто называют нисходящими методологиями, поскольку они 
начинаются на высшем уровне абстракции с конструкций "реального мира" 
("объектов" и т.д.) и заканчиваются на сравнительно низком уровне абстракции, 
представленном конкретной структурой макета базы данных. 
    Весь материал этой главы упорядочен следующим образом. Сначала приводится 
описание основных терминов, используемых в семантическом моделировании. Потом 
обсуждается наиболее известная из "расширенных" моделей— предложенная Ченом 
(Chen) модель типа объект/отношение (О/О), а затем рассматривается применение 
этой модели для проектирования базы данных. После этого предлагается краткий 
анализ некоторых аспектов модели О/О. И наконец, приводится резюме. 

    12.2. Общий подход 

    Общий подход к проблеме семантического моделирования характеризуется 
четырьмя основными этапами. 
    1.  Прежде всего следует попытаться задать множество семантических 
концепций (понятий), которые могут быть полезны при неформальном обсуждении 
реального мира. 
    • Например, можно согласиться с тем, что мир состоит из объектов. (Хотя 
невозможно с заданной точностью утверждать, что является объектом, а что— нет. 
Несмотря на это, концепция объектов весьма полезна для описания реального 
мира, по крайней мере с интуитивной точки зрения.) 

    332	Часть III. Проектирование базы данных 

    • Развивая эту концепцию, можно допустить, что объекты образуют типы 
объектов. Например, можно предположить, что все отдельные сотрудники являются 
экземплярами некоторого типа объекта EMPLOYEE (сотрудник). Преимущество такой 
группировки заключается в том, что все объекты определенного типа будут 
обладать некоторыми общими свойствами (например, получение сотрудниками 
зарплаты), а потому такая группировка может привести к некоторой (и совершенно 
очевидной) экономии представления. В реляционных терминах, например, общность 
выражается в заголовке отношения. 
    • Более того, можно согласиться с тем, чтобы каждый объект имел некое 
особое свойство, которое служит для идентификации этого объекта, т.е. с тем, 
чтобы каждый объект обладал идентичностью. 
    • Наконец, можно также предположить, что каждый объект может быть связан с 
другими объектами с помощью отношений. 
    И т.д. Однако здесь следует заметить, что все эти термины (экземпляр 
объекта, тип объекта, свойство, отношение и т.д.) определены не совсем точно 
или строго, поскольку некоторые из них являются всего лишь семантическими, а 
не формальными терминами. Например, первый термин не является формальным, а 
второй, третий и четвертый термины — являются. 
    2.  Далее нужно определить множество соответствующих символических (т.е. 
формальных) объектов, которые могут быть использованы для представления 
описанных выше семантических концепций. Например, в расширенной реляционной 
модели RM/T [12.5] предлагается несколько особых видов отношений, которые 
называются Е- и F'-отношениями. Грубо говоря, Е-отношения (от 
entity-relations) представляют объекты, а Р-отношения (от property-relations) 
— свойства, однако Е- и Р-отношения, конечно, имеют некоторые формальные 
определения, тогда как объекты и свойства их не имеют. 
    3.  Кроме того, нужно вывести множество формальных правил целостности для 
работы с такими формальными объектами. Например, модель типа RM/T содержит 
правило целостности под названием целостность свойств, которое утверждает, что 
для каждого элемента Р-отношения должен существовать соответствующий ему 
элемент Е-отношения (таким образом отражается тот факт, что каждое свойство 
должно быть свойством некоторого объекта). 
    4.  Наконец, следует задать множество формальных операторов для 
манипулирования этими формальными объектами. Например, в модели RM/T 
присутствует оператор PROPERTY, который можно использовать с Е-отношением и 
всеми соответствующими Р-отношениями таким образом, чтобы собрать вместе все 
свойства данного объекта. 
    Объекты, правила и операторы, описанные в пунктах 2-4, вместе образуют 
расширенную модель данных, если эти конструкции действительно являются 
супермножеством конструкций одной из базовых моделей, таких как, например, 
базовая реляционная модель. Хотя на самом деле в таком контексте нет четкого 
различия между расширенной и базовой моделью. Однако здесь следует обратить 
пристальное внимание на то, что правила и операторы являются такой же частью 
расширенной модели, как и объекты (точно так же, как это организовано в 
реляционной модели). Тем не менее, с точки зрения проектирования баз данных 
операторы являются менее важной частью модели по сравнению с объектами и 
правилами целостности. Поэтому за исключением нескольких комментариев, 
посвященных операторам, основное внимание в этой главе уделяется не 
операторам, а объектам и правилам. 
    В пункте 1 упоминалась попытка определения множества семантических 
концепций, которые были бы полезны при описании реального мира. Некоторые из 
них, а именно объекты, свойства, связи и подтипы, показаны на рис. 12.1. Для 
каждой из 

    Глава 12. Модель типа объект/отношение	333 

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

    Понятие  Неформальное определение_________Примеры_________________________ 
ОБЪЕКТ   Различимые объекты	Поставщик, товар, поставка, сотрудник, 
    отдел, человек, произведение, концерт, оркестр, дирижер, заказ, 
ассортимент заказов СВОЙСТВО Информация, описывакщзя о&ъект     Номер 
поставщика, количество поставок, 
    отдел сотрудника, рост человека, вид концерта, дата заказа 
    ОТНОШЕНИЕ Объект, который служит для органи- Поставка (поставщик-товар), 
назначение зации взаимодействия двух или не-   (сотрудник-отдел) скольких 
других объектов 
    ПОДТИП   Тип объекта Y является подтипом типа Тип "сотрудник" является 
подтипом типа объекта X тогда и только тогда, ко-  "человек" гда каящый объект 
типа Y обязательно является объектом типа X 

    Рис. 12.1. Некоторые полезные семантические концепции 

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

    12.3. Обзор модели объект/отношение 

    Вернемся к проблеме применения идей семантического моделирования для 
проектирования баз данных. Как уже упоминалось выше, одним из наиболее 
известных и широко распространенных подходов является так называемый подход 
типа объект/отношение— О/О. Этот подход был основан на предложенной в 1976 
году Ченом [12.3] "модели объект/отношение" и с тех пор неоднократно 
усовершенствовался Ченом и многими другими исследователями (об этом можно 
прочесть, например, в [12.4, 12.28, 12.29]). Дальнейшее обсуждение в этой 
главе в основном посвящено именно этому подходу. (Следует подчеркнуть, что эта 
модель является далеко не единственной "расширенной" моделью; их существует 
достаточно большое количество, например в [12.5, 12.13, 12.19, 12.25] 
приведены общие вводные сведения по некоторым из них, а в [12.15, 12.20] — 
вводные обзоры по данной тематике.) 
    Модель объект/отношение содержит аналоги всех семантических объектов, 
которые перечислены на рис. 12.1 и более подробно обсуждаются далее в этой 
главе. (Следует сразу же сказать, что, несмотря на некоторые различия в 
терминологии, большинство обсуждаемых идей имеет много общего с некоторыми 
чертами реляционной модели.) 

    334 Часть III. Проектирование базы данных 

    Замечание. В [12.3] представлена не только сама модель объект/отношение, 
но и соответствующая ей диаграммная техника или "О/О-диаграммы". Более 
подробно О/О-диаграммы описаны ниже, а на рис. 12.2 показан пример такой 
диаграммы из [12.3]. Этот пример с представлением структуры данных компании 
(расширенная версия О/О-диаграммы, приведенной на рис. 1.6 в главе 1) описан 
ниже и будет полезен при изучении последующего материала этой главы. 

    Рис. 12.2. Диаграмма модели объект/отношение 

    Объекты 

    Согласно определению, данному Ченом [12.3], объектом называется "предмет, 
который может быть четко идентифицирован". При этом объекты подразделяются на 
правильные объекты и слабые объекты. Слабым объектом называется объект, 
который находится в зависимости от некоторого другого объекта, т.е. он не 
может существовать, если не существует этот другой объект. Например, на рис. 
12.2 объекты DEPENDENT (подчиненный сотрудник) являются слабыми, поскольку они 
не могут существовать (в контексте данной базы данных), если не существует 
соответствующий объект EMPLOYEE (сотрудник). В частности, если данный 
сотрудник (EMPLOYEE) будет удален, то все зависящие от него объекты 
(DEPENDENT) также 

    Глава 12. Модель типа объект/отношение 335 

    будут удалены. Правильным объектом называется объект, который не является 
слабым: например, правильными объектами могут являться сотрудники. Некоторые 
авторы вместо термина "правильный объект" используют термин "сильный объект". 

    Свойства 

    Объекты (и отношения) обладают некоторыми свойствами (их также называют 
атрибутами, однако здесь этот термин применяться не будет, поскольку он уже 
имеет особое значение в реляционной модели). Все объекты одного типа обладают 
некоторыми общими свойствами: например, все сотрудники имеют номер, имя, 
зарплату и т.д. (В данном примере в качестве свойства сознательно не 
упоминается параметр "номер отдела", причина разъясняется несколько ниже.) 
Значения свойств каждого типа извлекаются из соответствующего множества 
значений, которое в реляционных терминах называется доменом. Ниже перечислены 
некоторые виды свойств и их особенности. 
    •   Простое или составное свойство (например, составное свойство "имя 
сотрудника" может складываться из простых свойств "имя", "промежуточные 
инициалы" и "фамилия"). 
    •   Ключевое свойство, уникальное в некотором контексте (например, имя 
подчиненного для определенного сотрудника уникально только в контексте этого сотрудника). 
    •  Однозначное или многозначное свойство (т.е. в данном случае разрешены 
повторяющиеся группы, однако эта концепция не представлена на рис. 12.2). 
    •   Отсутствующее свойство (т.е. "неизвестное" или "неприменимое", эта 
концепция не представлена на рис. 12.2). 
    •   Базовое или производное свойство (например, общее количество 
определенного товара может быть выведено на основе суммирования отдельных 
количеств поставок данного товара, эта концепция не представлена на рис. 12.2). 

    Отношения 

    В [12.3] отношение определяется как "ассоциация объектов". Например, между 
отделами и сотрудниками задано отношение (DEPT_EMP), которое означает, что в 
данном отделе работает заданное множество сотрудников. Так же, как и в случае 
с объектами, необходимо видеть принципиальную разницу между типами и 
экземплярами отношений, однако при неформальном описании такими тонкостями 
можно пренебречь. 
    Объекты, включенные в данное отношение, называются участниками этого 
отношения, а количество участников данного отношения называется степенью этого 
отношения. Следует отметить, что в данном случае значение термина "степень" 
несколько отличается от его значения в реляционной модели. 
    Пусть R является типом отношения, которое содержит тип объекта Е в 
качестве участника. Если каждый экземпляр типа объекта ? находится по крайней 
мере в одном экземпляре отношения R, то участие Е в отношении R называется 
полным, в противном случае — частичным. Например, если каждый товар должен 
поставляться по крайней мере одним поставщиком, то участие товаров в отношении 
между поставщиками и товарами (SUPP_PART) является полным. Но если допустима 
такая ситуация, когда некоторый товар не поставляется ни одним из поставщиков, 
то участие товаров в отношении SUPP_PART является частичным. 
    Отношения в модели объект/отношение могут иметь тип один-к-одному, 
один-ко-многим, многие-к-одному или многие-ко-многим (для упрощения изложения 
далее предполагается, что все отношения бинарные, т.е. степени два, хотя, 
конечно, изложение этих концепций и терминологию можно непосредственно 
расширить и на отношения более высокой степени). Здесь читатель, знакомый с 
основами реляционной модели, мог бы заметить, что случай отношения 
многие-ко-многим яв

    336	Часть III. Проектирование базы данных 

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

    Подтипы 

    Замечание. Идеи, представленные в этом разделе, не были включены в 
оригинальную модель объект/отношение [12.3], а были добавлены позднее. 
Подробнее об этом можно прочесть, например, в работе Теори, Янга и Фрая 
(Teorey, Yang, Fry) [12.28]. Каждый объект имеет по крайней мере один тип, 
однако у определенного объекта может быть несколько подтипов. Например, если 
некоторые сотрудники — программисты (а все программисты являются 
сотрудниками), то можно сказать, что тип PROGRAMMER (программист) является 
подтипом супертипа EMPLOYEE (сотрудник). Программисты автоматически обладают 
всеми свойствами сотрудников, однако обратное утверждение не верно (например, 
для программистов может быть задано свойство "язык программирования, которым 
программист владеет в наибольшей мере", в общем случае не применимое ко всем 
сотрудникам). Аналогично, программисты автоматически участвуют во всех 
отношениях, в которых участвуют сотрудники, однако обратное утверждение не 
верно (например, программисты могут входить в профессиональное компьютерное 
общество, в которое в общем случае сотрудники не входят). О таких свойствах и 
отношениях супертипа говорят, что они наследуются подтипом. (Наследование 
будет обсуждаться более подробно в последующих главах этой книги.) 
    Обратите внимание, что некоторые программисты (PROGRAMMER) могут быть 
прикладными программистами (APPLICATION_PROGRAMMER), а некоторые — системными 
(SYSTEM_PROGRAMMER). Таким образом, можно сказать, что типы 
APPLICATION_PROGRAMMER и SYSTEM_PROGRAMMER являются подтипами супертипа 
PROGRAMMER (и т.д.). Иначе говоря, подтип объекта все еще является типом 
объекта и может иметь собственные подтипы. Данный тип объекта, его 
непосредственные подтипы, подтипы подтипов и т.д. вместе образуют иерархию 
типов для данного типа объекта, пример которой показан на рис. 12.3. 
    
    
    |    EMPLOYEE   | 
    1 
    | PROGRAMMER) 
    i 
    г		~l 
    APPLICA" PROGRAI	riON                            SY VIMER                  
    PROC	STEM RAMMER 

    Рис. 12.3. Пример иерархии типов 

    Для читателей, знакомых с какой-нибудь системой, в которой поддерживается 
иерархическая структура данных, необходимо отметить, что иерархии типов не 
следует путать с иерархиями данных. На рис. 12.3, например, вовсе не 
подразумевается, что один сотрудник (EMPLOYEE) может иметь несколько 
соответствующих программистов (PROGRAMMER). Наоборот, для одного экземпляра 
типа EMPLOYEE существует максимум один соответствующий программист 
(PROGRAMMER), представляющий того же самого сотрудника (EMPLOYEE) в роли программиста. 

    Глава 12. Модель типа объект/отношение 337 

    На этом краткое обсуждение основных структурных особенностей модели 
объект/отношение завершено и можно перейти к рассмотрению диаграмм типа объект/отношение. 

    12.4. Диаграммы объект/отношение 

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

    Объекты 

    Каждый тип объекта показан в виде отдельного прямоугольника с его именем 
внутри, причем слабые типы объектов изображаются в двойной рамке. Примеры (см. 
рис. 12.2). 
    •   Правильные объекты: DEPARTMENT EMPLOYEE SUPPLIER PART PROJECT 
    •  Слабые объекты: DEPENDENT 

    Свойства 

    Свойства показаны в виде эллипсов с названием свойства, соединенных 
сплошной линией с соответствующим объектом (или отношением). Эллипс обведен 
штриховой линией, если свойство производное, и двойной линией, если свойство 
многозначное. Если свойство составное, то составляющие его свойства показаны в 
виде других эллипсов, соединенных с эллипсом составного свойства с помощью 
дополнительных линий. Ключевые свойства, как правило, подчеркиваются, а 
множества значений не показываются вовсе. 

    Примеры (см. рис. 12.2). 

    •  Для EMPLOYEE: 
    ЕМР# (ключевое свойство) 
    ENAME (составное, состоящее из свойств FIRST, MI и LAST) 
    SALARY 
    •  Для SUPPLIER: 
    S# (ключевое свойство) SNAME 

    338	Часть III. Проектирование базы данных 

    STATUS CITY 
    •   Для SUPP_PART_PROJ: QTY 
    •   Для PART_STRUCTURE: QTY Для экономии места другие свойства на рис. 
12.2 не показаны. 

    Отношения 

    Каждый тип отношения показан в виде ромба с названием отношения внутри. 
Ромб окружен двойной линией, если отношение задано между слабым типом объекта 
и типом объекта, от существования которого находится в зависимости слабый тип 
объекта. Участники каждого отношения присоединены к соответствующему отношению 
сплошными линиями. Каждая такая линия содержит надпись "1" или "М" для 
обозначения типа отношения, один-к-одному, один-ко-многим и т.д. Двойная линия 
обозначает полное участие. 
    Примеры (см. рис. 12.2). 
    •   DEPT_EMP (отношение типа один-ко-многим между объектами DEPARTMENT и EMPLOYEE) 
    •   EMP_DEP (отношение типа один-ко-многим между объектом EMPLOYEE и 
объектом слабого типа DEPENDENT) 
    •   PROJ_WORK и PROJ_MANAGER (оба отношения между объектами EMPLOYEE и 
PROJECT, первое имеет тип многие-ко-многим, а второе — один-ко-многим) 
    •   SUPP_PART_PROJ (отношение многие-ко-многим-ко-многим, включающее 
объекты SUPPLIER, PART и PROJECT) 
    •   SUPP_PART (отношение многие-ко-многим между объектами SUPPLIER и PART) 
    •   PART_STRUCTURE (отношение многие-ко-многим между объектами PART и PART) 
    Обратите внимание, что в последнем случае две линии от PART к 
PART_STRUCTURE отличаются своими надписями с указанием различных выполняемых 
"ролей" (ЕХР и IMP, которые обозначают соответственно "раскладывание товара по 
компонентам" и "складывание товара по компонентам"). Отношение PART_STRUCTURE 
является типичным примером рекурсивного отношения. 

    Подтипы и супертипы 

    Пусть Y является подтипом X, тогда от Y к X можно провести сплошную линию 
со стрелкой на конце для представления математического "подмножества" 
оператора (поскольку множество всех К является подмножеством множества всех 
X). Примеры (см. рис. 12.3, хотя стрелки на нем не показаны). 
    •   Тип PROGRAMMER является подтипом типа EMPLOYEE. 
    •   Типы   APPLICATION_PROGRAMMER   и   SYSTEM_PROGRAMMER  являются 
подтипами типа PROGRAMMER. 

    12.5. Проектирование базы данных на основе модели типа объект/отношение 

    В некотором смысле диаграмма объект/отношение, построенная в соответствии 
с описанными выше правилами, является (очень абстрактным) макетом базы данных. 
Если попытаться в таком макете формально отобразить некоторую СУБД, то скоро 

    Глава 12. Модель типа объект/отношение	339 

    станет ясно, что данная О/О-диаграмма недостаточно точна и в ней не задано 
множество деталей (особенно тех, которые относятся к целостности). Для 
иллюстрации этого утверждения рассмотрим содержание макета, показанного на 
рис. 12.2, с точки зрения понятий реляционной базы данных. 

    Правильные объекты 

    На рис. 12.2 показаны перечисленные ниже правильные объекты: DEPARTMENT 
EMPLOYEE SUPPLIER PART PROJECT 
    Каждый правильный тип объекта соответствует некоторому базовому отношению. 
Таким образом, рассматриваемая база данных будет содержать пять базовых 
отношений, например DEPT, EMP, S, Р и J, соответствующих этим пяти типам 
объектов. Более того, каждое из этих базовых отношений будет иметь первичный 
ключ — DEPT#, ЕМР#, S#, P# и J#, соответствующий "ключам", заданным в 
О/О-диаграмме. Все эти факты будут задокументированы с помощью 
соответствующего набора утверждений на языке определения данных (data 
definition language — DDL) или, по крайней мере, с помощью некоторых 
предпосылок для такого набора утверждений. (Иначе говоря, для записи решений, 
принятых при проектировании базы данных, предполагается использование 
DDL-утверждений. Хотя это не единственный способ выполнения данной функции, но 
какой бы формальный метод при этом не использовался, он должен быть 
функционально эквивалентен этим утверждениям.) Ниже в качестве примера в 
кратком виде приводится такое утверждение для отношения DEPT: 

    CREATE BASE RELATION DEPT 
    (  DEPTft DOMAIN   (  DEPT#  )    . . .   ) PRIMARY KEY   (   DEPT#   )   ; 

    Читателю в качестве упражнения предлагается сформулировать остальные утверждения. 
    Замечание. Домены и "множества значений" также должны быть 
задокументированы. Однако подробное описание этой темы здесь опускается, 
поскольку, как уже упоминалось выше, на данной О/О-диаграмме множества 
значений не показаны. 

    Отношения типа многие-ко-многим 

    В рассматриваемом примере есть следующие отношения типа многие-ко-многим: 
PROJ_WORK (между сотрудниками и проектами); SUPP_PART (между поставщиками и 
товарами); SUPP_PART_PROJ (между поставщиками, товарами и проектами); 
PART_STRUCTURE (между товарами и товарами). 
    Каждая такая зависимость соответствует некоторому базовому отношению. 
Таким образом, вводится еще четыре базовых отношения, соответствующих этим 
четырем зависимостям. Допустим, таким базовым отношением для SUPP_PART 
является SP (обычное отношение между поставщиками и товарами). Теперь можно 
отвлечься от описания первичного ключа для этого отношения и обратить внимание 
на внешние ключи, которые необходимы для идентификации участников данной зависимости. 

    CREATE BASE RELATION SP 
    ( S# ..., P# ...,...) 
    FOREIGN KEY ( S# ) REFERENCES S FOREIGN KEY ( P# ) REFERENCES P ; 

    340	Часть III. Проектирование базы данных 

    Ясно, что такое отношение должно включать два внешних ключа (S# и Р#), 
соответствующих двум участникам (поставщикам и товарам), и эти внешние ключи 
должны обращаться к соответствующим отношениям поставщиков S и Р. Более того, 
соответствующий набор правил для внешних ключей, т.е. правило обновления и 
правило удаления, должны быть заданы для каждого из этих внешних ключей (за 
более подробными сведениями по этой теме следует обращаться к главе 5). 
(Отметим, что здесь полностью игнорируется обработка пустой информации. В 
частности, здесь не рассматривается возможность использования во внешних 
ключах пустых значений, что подразумевает игнорирование и правила обработки 
пустой информации для внешних ключей, и опции NULLIFIES для правил обновления 
и удаления во внешних ключах.) В случае базового отношения SP следует задать 
приведенные ниже правила. (Эти правила, конечно, приведены в качестве 
иллюстрации; обратите, например, внимание на то, что они не связаны с помощью О/О-диаграммы.) 

    CREATE BASE RELATION SP 
    ( S# ... , P# ...,...) 
    FOREIGN KEY ( S# ) REFERENCES S 
    DELETE RESTRICTED 
    UPDATE CASCADES FOREIGN KEY ( P# ) REFERENCES P 
    DELETE RESTRICTED 
    UPDATE CASCADES ; 

    Что можно сказать о первичном ключе этого отношения? Одним из способов его 
определения могла бы быть комбинация внешних ключей, которые идентифицируют 
участников (в случае базового отношения SP это S# и Р#), если эта комбинация 
имеет уникальное значение для каждого экземпляра этого отношения (обычно так и 
бывает, хотя могут быть и обратные случаи), если в ней содержится условие 
NULLS NOT ALLOWED, т.е. null-значения недопустимы (обычно так и бывает, хотя 
могут быть и обратные случаи), и если разработчик базы данных не возражает 
против использования составных первичных ключей (на практике это в равной 
степени возможно и невозможно). (Второе из перечисленных условий требуется для 
удовлетворения правила целостности объектов базового отношения SP. Как уже 
упоминалось выше, в рассматриваемом примере в любом случае все внешние ключи 
будут иметь статус NULLS NOT ALLOWED, так что этот вопрос не имеет никакого 
отношения к данному обсуждению.) В качестве альтернативного варианта 
первичного ключа можно использовать новый несоставной атрибут "номер 
поставки". В рассматриваемом примере будет использован первый из двух 
описанных выше вариантов. Таким образом, в утверждение CREATE BASE RELATION 
для SP следует добавить директиву 

    PRIMARY KEY   (  S#,   P#   ) 

    Читателю предлагается самостоятельно рассмотреть в качестве упражнения 
отношения PROJ_WORK, PART_STRUCTURE и SUPP_PART_PROJ. 

    Отношения типа многие-к-одному 

    В рассматриваемом примере заданы три отношения типа многие-к-одному: 
PROJ_MANAGER (между проектами и менеджерами); DEPT_EMP (между сотрудниками и 
отделами); EMP_DEP (между подчиненными и сотрудниками). 
    Только последнее отношение содержит слабый тип объекта (DEPENDENT), а два 
других — правильные типы объектов. Отношение со слабым типом объекта 
рассматривается несколько позже, а сейчас рассмотрим какое-либо из двух 
других, например DEPTJEMP. В таком примере не нужно вводить никаких новых 
отношений. Вместо этого достаточно просто ввести приведенный ниже внешний ключ 
со стороны "многие" (ЕМР), который обращается к отношению со стороны "один" (DEPT): 

    Глава 12. Модель типа объект/отношение	341 

    CREATE BASE RELATION EMP 
    ( EMP# ... , DEPT# ... , ... ) 
    PRIMARY KEY ( EMP# ) 
    FOREIGN KEY ( DEPT# ) REFERENCES DEPT 
    DELETE ... 
    UPDATE ... ; 

    В данном случае возможности для правил внешних ключей точно такие же, что 
и для внешнего ключа, который представляет участника отношения типа 
мно-гие-ко-многим в общем случае. Здесь вновь следует отметить, что они не 
показаны на данной О/О-диаграмме. 
    Замечание. В рассматриваемом примере предполагается, что отношения типа 
один-к-одному (которые в общем случае не очень распространены на практике) 
следует рассматривать точно так же, как и отношения многие-к-одному. Подробное 
описание особенностей использования отношений типа один-к-одному приводится в [12.9]. 

    Слабые объекты 

    Связь слабого типа объекта с сильным, от которого он зависит, конечно, 
является связью типа многие-к-одному, как это уже отмечалось. Однако внешние 
ключи для этой связи должны выглядеть так, как показано ниже. (Кроме того, 
если задано правило для обработки пустой информации, оно должно выглядеть как 
NULLS NOT ALLOWED.) 

    DELETE CASCADES UPDATE CASCADES 

    Взятые вместе, эти правила выражают необходимую зависимость существования, 
которая иллюстрируется следующим примером: 

    CREATE BASE RELATION DEPENDENT ( EMPl . . . ) 
    FOREIGN KEY ( EMP# ) REFERENCES EMP DELETE CASCADES UPDATE CASCADES ; 

    Что является первичным ключом для данного отношения? Как и в случае с 
отношением многие-ко-многим, здесь также можно осуществить выбор. Одним из 
вариантов является комбинация внешнего ключа и "ключа" слабого объекта из 
О/О-диаграммы, если (опять) разработчик базы данных не имеет возражений против 
использования составных первичных ключей. Альтернативным вариантом первичного 
ключа является введение нового несоставного атрибута. В рассматриваемом 
примере опять применяется первый из двух приведенных выше вариантов с 
использованием следующей директивы (в которой DEPJNAME является именем 
подчиненного данного сотрудника) в утверждении CREATE BASE RELATION для 
базового отношения DEPENDENT: 

    PRIMARY KEY ( ЕМР#, DEP_NAME ) 

    Свойства 

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

    Супертипы и подтипы 

    Поскольку на рис. 12.2 не содержится никаких супертипов и подтипов, далее 
речь пойдет о примере, представленном на рис. 12.3. Каждому типу объекта на 
этом рисунке соответствует некоторое базовое отношение с атрибутами для 
свойств, которые применяются на заданной позиции внутри иерархии типов (а 
значит, наследуются на всех подчиненных позициях, но не на тех, которым они 
подчиняются). Рассмотрим, 

    342	Часть III, Проектирование базы данных 

    например, базовые отношения, ЕМР и PGMR, соответствующие типам объектов 
EMPLOYEE и PROGRAMMER: 

    CREATE BASE RELATION EMP 
    ( EMP# ... , DEPT# ... , SALARY ... , ... ) PRIMARY KEY ( EMP# ) ; 
    CREATE BASE RELATION PGMR 
    ( EMP# ... , LANG ... , ... ) 
    PRIMARY KEY ( EMP# ) 
    FOREIGN KEY ( EMP# ) REFERENCES EMP ... ; 

    Здесь атрибут LANG представляет свойство "язык программирования, которым 
программист владеет в наибольшей мере", присущее только тем сотрудникам, 
которые являются программистами. Обратите внимание, что отношения ЕМР и PGMR 
обладают одинаковыми первичными ключами (ЕМР#); более того, первичный ключ для 
подчиненного типа (PGMR) также служит внешним ключом, который обращается к 
первичному ключу супертипа (ЕМР). Читателю предлагается самостоятельно выбрать 
соответствующий набор правил для этого внешнего ключа, а также разобраться с 
другими типами объектов, показанными на рис. 12.3 (APPLICATION_PROGRAMMER и SYSTEM_PROGRAMMER). 

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

    В этом разделе кратко рассматриваются некоторые другие аспекты модели типа 
объект/отношение. Большая часть излагаемого здесь материала взята из другой 
работы автора [12.7], в которой эта тема обсуждается подробнее. 
    Модель объект/отношение как основа реляционной модели 
    Рассмотрим подход на основе модели объект/отношение с несколько иной точки 
зрения. Вероятно, идеи, основанные на таком подходе или близкие к ним, с точки 
зрения Кодда, составляли неформальную основу при создании формальной 
реляционной модели. Как уже объяснялось выше в этой главе, общий подход к 
семантическому моделированию включает четыре больших этапа; цель каждого из 
них можно кратко сформулировать следующим образом: 
    1.	Идентифицировать полезные семантические концепции. 
    2.	Вывести формальные объекты. 
    3.	Вывести формальные правила целостности. 
    4.	Вывести формальные операторы. 
    Обратите внимание, что эти четыре этапа также применимы для проектирования 
базовой реляционной модели (и для любой формальной модели данных), а не только 
для "расширенных" моделей типа объект/отношение. Иначе говоря, для того чтобы 
создать (формальную) базовую реляционную модель, Кодд прежде всего должен был 
разработать некоторые (неформальные) "полезные семантические концепции", 
основанные либо на идеях модели объект/отношение, либо на подобных им 
концепциях. Действительно, работы Кодда подтверждают это, поскольку в его 
первой статье [4.2], посвященной реляционной модели, приведены следующие строки: 
    "Множество объектов заданного типа объекта можно рассматривать как 
отношение, и мы будем называть такое отношение отношением типа объекта... 
Оставшиеся отношения ... между типами объектов и ... называются межобъектными 
отношениями... Существенным свойством каждого межобъектного отношения является 
то, что [оно содержит, по крайней мере, два внешних ключа, которые] обращаются 
к различным типам объектов либо к общему типу объекта, выполняющему различные роли". 

    Глава 12. Модель типа объект/отношение	343 

    Здесь Кодд в ясной форме предлагает, чтобы отношения использовались для 
моделирования и "объектов", и "зависимостей". Но самое главное заключается в 
том, что отношения являются формальными объектами, а реляционная система — 
формальной системой. Ценность научного вклада Кодда состоит в том, что он 
нашел удачную формальную модель для некоторых аспектов реального мира. 
    Наоборот, модель объект/отношение не является (или, по крайней мере, не в 
первую очередь является) формальной моделью. Действительно, она 
преимущественно состоит из набора неформальных, концепций, соответствующих 
(только) первому из четырех приведенных выше этапов. (Более того, ее 
формальные аспекты на самом деле не очень значительно отличаются от 
соответствующих аспектов основной реляционной модели; обсуждение этого вопроса 
будет продолжено далее.) Для проектирования базы данных, несомненно, полезно 
иметь в своем распоряжении (помимо прочих) "непробиваемые" концепции, 
представленные на этапе 1. Однако немаловажным остается тот факт, что 
проектирование базы данных не может быть выполнено без формальных объектов и 
правил, представленных на этапах 2 и 3, а многие другие задачи вовсе не могут 
быть выполнены без использования формальных операторов этапа 4. 
    Следует отметить, что перечисленные выше замечания не означают 
бесполезности модели объект/отношение, скорее наоборот. Еще более странным 
кажется то, что впервые описание неформальной модели объект/отношение было 
опубликовано несколько лет спустя после публикации описания формальной 
реляционной модели, изначально основанной на некоторых идеях модели объект/отношение. 
    Является ли модель объект/отношение моделью данных 
    Исходя из изложенного, не совсем ясно, является ли модель объект/отношение 
на самом деле моделью данных, по крайней мере в предложенном в этой книге 
смысле (т.е. как формальная система, включающая структурные аспекты, аспекты 
целостности и манипулирования). Конечно, термин "моделирование типа 
объект/отношение" обычно используется для обозначения процесса выбора (только) 
структуры базы данных, хотя выше в этой главе рассматривались некоторые 
аспекты целостности. Однако при более внимательном чтении оригинальной статьи 
Чена можно предположить, что модель объект/отношение действительно является 
моделью данных, но такой, которая представляет собой лишь тонкий слой на 
вершине базовой реляционной модели (и конечно, не может заменить реляционную 
модель, как хотелось бы некоторым разработчикам). Это утверждение можно 
обосновать приведенными ниже доводами. 
    •  Прежде всего, фундаментальный элемент данных для модели 
объект/отношение, т.е. фундаментальный формальный элемент, который является 
противоположностью неформальным элементам — "объекту", "зависимости" и т.д., 
является отношение степени п. 
    •  Операторы модели объект/отношение в основном являются операторами 
реляционной алгебры. (Действительно, работу [12.3] нельзя назвать очень ясной 
в этом отношении, но в ней предлагается менее мощное по сравнению с 
реляционной алгеброй множество операторов, среди которых, например, не 
существует объединения и явно заданного соединения.) 
    •  Именно в вопросах целостности эти два подхода в некоторой степени 
отличаются друг от друга: модель объект/отношение содержит набор встроенных 
правил целостности, соответствующих некоторым, но не всем правилам внешнего 
ключа, описанным в главе 5 этой книги. Таким образом, там, где для "чистой" 
реляционной системы потребовалось бы явно сформулировать некоторые правила для 
внешних ключей, для модели объект/отношение достаточно было указать, что 
данное отношение имеет некоторый тип, и соответствующие правила для внешних 
ключей были бы задействованы. 

    344	Часть III. Проектирование базы данных 

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

    В этой книге уже несколько раз отмечалось, что "отношения" лучше всего 
рассматривать всего лишь как определенного рода объекты. И наоборот, 
обязательным условием модели объект/отношение является то, что эти два понятия 
должны каким-то образом различаться. По мнению автора, любой подход, в котором 
преследуется такое разделение, обладает серьезными недостатками, поскольку, 
как уже отмечалось выше в этой главе, один и тот же элемент может совершенно 
справедливо рассматриваться как объект одними пользователями и как отношение — 
другими. В этой связи можно рассмотреть следующий пример заключения брака. 
    •   С одной стороны, браком называется некоторая связь между двумя людьми. 
В качестве примера можно привести запрос: "С кем вступила в брак Элизабет 
Тейлор в 1975 году?" 
    •   С другой стороны, брак является своего рода объектом. В качестве 
примера можно привести следующий запрос: "Сколько браков было заключено в этой 
церкви с апреля?" 
    Если в методике проектирования базы данных предполагается наличие 
некоторых различий между "объектом и отношением", то в лучшем случае эти две 
интерпретации будут рассматриваться асимметрично (т.е. запросы для "объектов" 
и запросы для "отношений" буду выглядеть совершенно по-разному). А в худшем 
случае одна интерпретация вовсе не будет поддерживаться (т.е. один из классов 
запроса будет невозможно сформулировать). 
    В качестве еще одной иллюстрации рассмотрим следующее утверждение о модели 
объект/отношение из [12.10]: 
    "Обычно сначала следует представить некоторые отношения в виде атрибутов 
[которые в данном случае означают внешние ключи] для концептуальной схемы 
проектирования, а затем преобразовать эти атрибуты в отношения по мере 
дальнейшего развития и более глубокого понимания процесса проектирования". 
    Но что произойдет, если атрибут станет внешним ключом еще позже, т.е. если 
база данных будет изменена после того, как она использовалась в течение 
некоторого времени? Если эту идею логически развивать, то можно прийти к 
выводу, что макет базы данных должен содержать только отношения и совсем 
никаких атрибутов! 

    12.7. Резюме 

    Эта глава начиналась с краткого введения в общие идеи семантического 
моделирования. В целом этот процесс состоит из четырех перечисленных ниже 
этапов, первый из которых является неформальным, а остальные — формальными. 
    1.	Задать полезные семантические концепции. 
    2.	Вывести соответствующие символические объекты. 
    3.	Вывести соответствующие правила целостности. 
    4.	Вывести соответствующие операторы. 
    Среди полезных семантических концепций следует упомянуть объект, свойство, 
отношение и подтип. 
    Главная цель исследований в области семантического моделирования 
заключается в том, чтобы сделать СУБД более "разумными". А практическая цель 
заключается в создании системного подхода к решению проблемы проектирования 
базы данных. В данной главе было описано применение частной "семантической" 
модели для решения этой проблемы, а именно предложенной Ченом модели объект/отношение. 
    В связи со сказанным выше стоит повторить мысль о том, что в оригинальной 
статье Чена [12.3] на самом деле содержалось два различных, более или менее 
неза

    Глава 12. Модель типа объект/отношение	345 

    висимых, предложения: сама модель объект/отношение, а также диаграммная 
техника. Как было отмечено, популярность модели объект/отношение скорее всего 
можно объяснить именно наличием этой диаграммной техники, чем какой-либо 
другой причиной. Однако совсем не обязательно для использования диаграмм 
принимать все идеи этой модели. Диаграммы можно использовать в качестве основы 
для любой методики проектирования, например в [12.6] приводится другая 
методика. Часто при сравнении удобства использования модели объект/отношение и 
других моделей, предусмотренных для проектирования базы данных, эта 
особенность упускается из виду. Сравним теперь идеи семантического 
моделирования (и модель объект/отношение в частности) с порядком нормализации, 
описанным в главах 10 и 11. Порядок нормализации основан на приведении больших 
отношений к отношениям меньшего размера. При этом предполагается, что на 
исходном этапе имеется небольшое количество больших отношений и после 
выполнения нескольких операций приведе ния на завершающем этапе будет получено 
большое количество малых отношений, т.е. произойдет отображение больших 
отношений на малые (это, конечно же, очень приблизительная формулировка). 
Однако в процедуре нормализации нигде не упоминается, каким образом были 
получены исходные большие отношения. Нисходящие методики, подобные описанным в 
настоящей главе, как раз и предназначены для решения именно этой проблемы, 
т.е. они позволяют отобразить реальный мир в больших отношениях. Иначе говоря, 
эти два подхода дополняют друг друга. Таким образом, общая процедура 
проектирования базы данных включает два этапа. 
    1. Использование подхода на основе модели объект/отношение или другой 
нисходящей методики для генерации "больших" отношений, представляющих 
правильные объекты, слабые объекты и т.д. 
    2.  Последующее использование идей дальнейшей нормализации для разбиения 
"больших" отношений на "малые". 
    Однако, судя по приведенным в данной главе рассуждениям, изложение основ 
семантического моделирования не является таким строгим и ясным, как описание 
порядка дальнейшей нормализации в главах 10 и 11. Дело в том, что (как было 
указано в начале данной главы) проектирование базы данных все еще является не 
объективным, а весьма субъективным занятием, поскольку существует сравнительно 
мало действительно строгих принципов, которые могут использоваться для 
разрешения этой проблемы (немногие существующие на сегодняшний день принципы в 
основном являются принципами нормализации). Изложенные в настоящей главе идеи 
можно рассматривать как рекомендации, которые действительно могут быть весьма 
полезны на практике. 
    В заключение следует упомянуть еще один очень важный момент. Несмотря на 
заявление, что эта область исследований все еще остается очень субъективной, 
есть в ней одна особая часть, в которой идеи семантического моделирования в 
настоящее время могут быть весьма уместны и полезны. Речь идет о словаре 
данных, который в некотором смысле можно рассматривать как "базу данных 
разработчика для создаваемой им базы данных". В ней разработчик хранит 
принятые во время проектирования базы данных решения [12.2]. Таким образом, 
изучение семантического моделирования может оказаться чрезвычайно полезным для 
проектирования системы управления словарем данных. В нем могут быть указаны 
типы объектов, которые словарь должен поддерживать и "понимать", например 
категории объектов (такие как правильные и слабые объекты в модели 
объект/отношение), правила целостности (такие как полное или частичное участие 
в отношении модели объект/отношение), супертипы объектов, подтипы и т.д. 

    Упражнения 

    12.1. Что означает термин "семантическое моделирование"? 
    12.2. Перечислите   четыре   основных   этапа,   необходимых   для   
задания   такой "расширенной" модели, как модель объект/отношение. 

    346	Часть III. Проектирование базы данных 

    12.3. Дайте определение перечисленным терминам модели объект/отношение: 
объект; правильный объект; слабый объект; отношение; свойство; ключевое 
свойство; супертип; подтип; иерархия типов; наследование. 
    12.4. Приведите примеры для следующих отношений: 
    а) отношение типа многие-ко-многим, в котором один из участников является 
слабым объектом; 
    б) отношение типа многие-ко-многим, в котором один из участников является 
другим отношением; 
    в) отношение типа многие-ко-многим, которое имеет подтип; 
    г) подтип, связанный со слабым объектом, который, в свою очередь, не 
зависит от супертипа. 
    12.5. Нарисуйте диаграмму объект/отношение для базы данных учебного 
процесса из упр. 5.3 главы 5. 
    12.6. Нарисуйте диаграмму объект/отношение для базы данных, содержащей 
информацию о персонале компании, из упр. 10.3 главы 10. Используйте эту 
диаграмму для вывода соответствующего набора базовых отношений. 
    12.7. Нарисуйте диаграмму объект/отношение для базы данных системы учета 
заказов из упр. 10.4 главы 10. Используйте эту диаграмму для вывода 
соответствующего набора базовых отношений. 
    12.8. Нарисуйте диаграмму объект/отношение для базы данных, содержащей 
информацию о продажах, из упр. 11.2 главы 11. Используйте эту диаграмму для 
вывода соответствующего набора базовых отношений. 
    12.9. Нарисуйте диаграмму объект/отношение для измененной базы данных о 
продажах из упр. 11.4 главы 11. Используйте эту диаграмму для вывода 
соответствующего набора базовых отношений. 

    Список литературы 

    Сюда следует также отнести некоторые  ссылки на работы,  приведенные  
после главы 2, особенно [2.3, 2.6, 2.7]. 
    12.1. Abrial J.R. Data Semantics // J. W. Klimbie and K. L. Koffeman 
(eds.). Data Base Management.— Amsterdam, Netherlands: North-Holland; New 
York, N.Y.: Elsevier Science, 1974. 
    Одна из самых ранних публикаций в области семантического моделирования. 
Следующая цитата прекрасно передает общий дух изложения материала в этой 
статье: "Совет читателю: если вы хотите найти в этой статье определение 
термина семантика, вам следует прекратить чтение, поскольку такого определения 
в этой статье нет". 
    12.2. Alien F.W., Loomis M.E.S., Mannino M.V. The Integrated 
Dictionary-Directory System // ACM Сотр. Surv. — 1982. — 14, № 2. 
    Введение в словари данных с кратким обзором имеющихся продуктов по 
состоянию на 1982 год. 
    12.3. Chen P. P.-S. The Entity-Relationship Model — Toward a Unified View 
of Data // ACM TODS. — 1976. — 1, № 1. (Переиздано: М. Stonebraker (ed.) 
Readings in Database Systems. — San Mateo, Calif.: Morgan Kaufmann, 1988.) 
    В статье представлены модель и диаграмма объект/отношение. Как уже 
говорилось в этой главе, с тех пор эта модель претерпела значительные 
изменения, поскольку, конечно же, объяснения и определения, данные в этой 
первой статье были не очень строгими и точными, а потому нуждались в 
усовершенствовании. (Одно из наиболее часто высказываемых критических 
замечаний по отношению к 

    Глава 12. Модель типа объект/отношение	347 

    модели объект/отношение состоит в том, что термины модели не имеют единого 
и четкого определения, а интерпретируются несколькими различным способами 
[12.4, 12.7]. Конечно, вся область изучения баз данных характеризуется 
наличием неточной и противоречивой терминологии, однако данная область — в 
наибольшей степени.) Вот несколько примеров этих неточностей. 
    • В этой главе отмечалось, что объект определяется как "предмет, который 
может быть четко идентифицирован", а отношение как "соединение объектов". При 
этом сразу же возникает вопрос, а является ли отношение объектом? Ясно, что 
отношение является "предметом, который может быть четко идентифицирован", 
однако из последующих разделов этой статьи следует, что термин "объект" 
предусмотрен для чего-то, определенно не являющегося "отношением". Если все же 
допустить, что это так, то почему модель называется "моделью 
объект/отношение"? В статье это действительно не очень ясно. 
    • Объекты и отношения могут иметь атрибуты (в этой статье использовался 
термин "свойство"). В статье снова не дается четкого определения этому 
термину, поскольку сначала атрибут определяется как свойство, которое не 
является первичным ключом или его компонентом (в противоположность 
реляционному определению), а потом он используется в стандартном реляционном смысле. 
    • Предполагается, что первичный ключ отношения является комбинацией 
внешних ключей, которые идентифицируют объекты, включенные в состав данного 
отношения (однако термин "внешний ключ" при этом не используется). Это 
допущение верно только для отношений типа многие-ко-многими и то не всегда. 
Например, рассмотрим отношение SPD {S#, P#, DATE, QTY}, представляющее 
поставки некоторых товаров некоторыми поставщиками по некоторым датам. 
Предположим, что один и тот же поставщик может поставлять один и тот же товар 
несколько раз, но только по разным датам. Тогда первичный ключ является 
комбинацией (S#, P#, DATE}, причем если поставщиков и товары можно выбрать в 
качестве объектов, то для дат этого сделать нельзя. 
    12.4. Chen P. P.-S. A Preliminary Framework for Entity-Relationship Models 
// P. P.-S. Chen (ed.). Entity-Relationship Approach to Information Modeling 
and Analysis. — Saugus, Calif, 1981. 
    12.5. Codd E.F. Extending the Database Relational Model to Capture More 
Meaning // ACM TODS. — 1979. — 4, № 4. 
    В статье представлена расширенная реляционная модель RM/T. Можно сразу же 
отметить несколько различий между RM/T и моделью объект/отношение. Во-первых, 
в модели RM/T не делается никаких различий между объектами и отношениями 
(отношение рассматривается всего лишь как особый вид объекта). Во-вторых, 
структурные и целостные аспекты модели RM/T более обширны и менее четко 
определены, чем в модели объект/отношение. В-третьих, модель RM/T содержит 
несколько специальных операторов в дополнение к операторам базовой реляционной 
модели (хотя в этой области еще предстоит дополнительная работа). 
    Вкратце модель RM/T функционирует следующим образом. 
    • Объекты (включая "отношения") представлены Е-отношениями и 
Р-отноше-ниями, которые являются особыми видами отношения общего типа степени 
п. Е-отношения используются для указания существования некоторых объектов, а 
Р-отношения — для указания некоторых свойств этих объектов. 
    • Среди объектов могут быть заданы разные отношения: например, типы 
объектов А и В могут образовывать соединение (этот термин принят в модели RM/T 
для отношения типа многие-ко-многим) или один тип объекта может быть подтипом 
другого типа объекта. Модель RM/T имеет формальную структуру каталога, который 
указывает системе на существование таких отношений. Таким образом, система в 
состоянии привести в действие различные ограничения целостности, которые 
подразумеваются наличием таких отношений. 

    348	Часть III. Проектирование базы данных 

    • Для управления различными объектами модели RM/T (Е- и Р-отношения, 
каталог отношений и т.д.) существуют операторы высокого уровня. 
    В модели RM/T имеются и другие аналоги конструкций модели объект/отношение 
(объект, свойство, отношение, подтип), которые перечислены на рис. 12.1. 
Точнее, в ней задана классификационная схема объектов, которая во многих 
случаях образует наиболее значительный или, по крайней мере, наиболее 
очевидный аспект всей этой модели. Объекты разделены на три основные 
категории: ядра, характеристики и соединения. 
    • Ядра. Это объекты, имеющие независимое существование, они являются тем, 
из "чего на самом деле состоит база данных". Иначе говоря, ядрами называются 
объекты, которые не являются ни характеристиками, ни соединениями. 
    • Характеристики. Это объекты, предназначенные для описания или 
"составления характеристики" некоторого другого объекта. Характеристики 
существуют независимо от описываемых ими объектов. Описываемый объект может 
быть ядром, характеристикой или соединением. 
    • Соединения. Это объекты, представляющие отношение типа многие-ко-многим 
(или многие-ко-многим-ко-многим и т.д.) среди двух или более объектов. Среди 
соединенных объектов могут быть ядра, характеристики или соединения. 
    Кроме того: 
    • Объекты (независимо от их классификации) могут также быть свойствами. 
    • В частности, любой объект (опять-таки независимо от классификации) может 
иметь свойство, функция которого заключается в том, чтобы указать на некоторый 
другой объект. Такое указание представляет собой отношение типа 
многие-к-одному между двумя объектами. 
    • Поддерживаются супертипы и подтипы объектов. Если В является супертипом 
А, то В является ядром, характеристикой или соединением в зависимости от того, 
является ли А ядром, характеристикой или соединением. 
    Все перечисленные выше концепции можно соотнести с их аналогами в модели 
объект/отношение (в некотором неформальном виде) следующим образом. Ядро 
соответствует "правильному объекту" в модели объект/отношение, характеристика 
— "слабому объекту", а соединение — "отношению" (только для типа многие-ко-многим). 
    Приведенные выше краткие сведения следует дополнить упоминанием о том, что 
в модели RM/T предусмотрена поддержка суррогатов (подробнее это описано в 
[12.12]), временного измерения и различных типов агрегации данных (подробнее 
это обсуждается в [12.22, 12.23]). 
    12.6. Date C.J. A Practical Approach to Database Design // С. J. Date. 
Relational Database: Selected Writings. — Reading, Mass.: Addison-Wesley, 
1986. Описание методики проектирования, основанной на концепциях модели RMAT [12.5]. 
    12.7. Date C.J. Entity/Relationship Modeling and the Relational Model // 
C. J. Date and Hugh Darwen. Relational Database Writings: 1989-1991.— Reading, 
Mass.: Addison-Wesley, 1992.. 
    12.8. Date C.J. Don't Encode Information into Primary Keys! // Ibid. 
    Здесь представлены аргументы против того, что порой называется "разумными 
ключами". Кроме того, также следует упомянуть работы [5.6, 5.7], в которых 
приведены рекомендации относительно внешних ключей. 
    12.9. Date C.J. A Note on One-to-One Relationships // С. J. Date. 
Relational Database Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990. 
    Обширное обсуждение проблемы отношений типа один-к-одному, которые на 
самом деле гораздо сложнее, чем может показаться на первый взгляд. 

    Глава 12. Модель типа объект/отношение	349 

    12.10. Elmasri R., Navathe S.B. Fundamentals of Database Systems (2nd 
edition).— Redwood City, Calif: Benjamin/Cummings, 1994. 
    В этом учебном пособии о проектировании баз данных содержится две главы, 
посвященные методам объект/отношение. 
    12.11. Fleming С.С., Von Halle В. Handbook of Relational Database Design. 
— Reading, Mass.: Addison-Wesley, 1989. 
    Достаточно обширное и прекрасное в практическом отношении пособие по 
проектированию баз данных в реляционных системах с некоторыми примерами на 
основе системы DB2 компании IBM и DBC/1012 компании Teradata (теперь NCR). 
Описана как логическая, так и физическая структура, хотя, например, для 
описания "реляционного макета" в книге используется термин "логический макет", 
а с помощью термина "реляционный макет" описаны по крайней мере некоторые 
аспекты "физического макета"! Описанная в этой книге особая методика 
проектирования имеет несколько общих черт с методикой, представленной в [12.6]. 
    12.12. Hall P., Owlett J., Todd S.J.P. Relations and Entities // G. M. 
Nijssen (ed.). Modelling in Data Base Management Systems. — Amsterdam, 
Netherlands: North-Holland; New York, N.Y.: Elsevier Science, 1975. 
    Это первая статья, в которой была подробно рассмотрена идея суррогатов 
(позднее суррогаты были введены в состав модели RM/T). Суррогатом называется 
идентификатор объекта, заданный и поддерживаемый самой системой. В терминах 
модели RM/T каждое Е- и Р-отношение имеет суррогат в качестве первичного 
ключа, который в случае Р-отношений служит также внешним ключом (обращаясь к 
соответствующему Е-отношению). В этой статье подробно обсуждаются некоторые 
преимущества суррогатов. Здесь, вероятно, стоит заметить, что суррогаты не 
являются (как считают некоторые авторы) тем же, что и "идентификаторы 
кортежей", потому что последние идентифицируют кортежи, а суррогаты 
идентифицируют объекты, а значит, между ними не может быть никакого отношения 
типа один-к-одному. На самом деле между объектами и кортежами существует 
отношение типа один-к-одному только в случае Е-отношений (в терминах модели 
RM/T). Отсюда следует, что кортежи в базовых отношениях, отличных от 
Е-отношений, и кортежи в производных отн ошениях не имеют вовсе никакой 
очевидной связи с суррогатами. Более того, идентификаторы кортежей обладают 
дополнительными преимуществами в производительности, что не свойственно 
суррогатам, поскольку доступ к кортежу через идентификатор кортежа происходит 
очень быстро (предполагается, что кортежи [базового отношения] отображаются 
непосредственно на физическую структуру хранения; это имеет место во многих 
современных реляционных программных продуктах). Кроме того, идентификаторы 
кортежа обычно скрыты от пользователя, тогда как суррогаты обычно нет, т.е. 
идентификатор кортежа нельзя сохранить как значение атрибута, а суррогат 
можно. Короче говоря, суррогаты являются логической концепцией, а 
идентификаторы кортежей — физической. 
    12.13. Hammer M.M., McLeod D. J. The Semantic Data Model: A Modelling 
Mechanism for Database Applications // Proc. 1978 ACM SIGMOD Intern. Conf. on 
Management of Data. —Austin, Texas, 1978. 
    Семантическая модель данных (Semantic Data Model — SDM) представляет собой 
другой формальный подход проектирования базы данных. Как и в модели 
объект/отношение, основное внимание в ней уделяется структурным аспектам и 
аспектам целостности и совсем немного внимания (или вообще никакого) — 
аспектам манипулирования (операторам). Об этом также можно прочесть в [12.14, 12.16]. 
    12.14. Hammer M., McLeod D. Database Description with SDM: A Semantic 
Database Model // ACM TODS. — 1981. — 6, № 3. См. комментарий к [12.13]. 

    350	Часть III. Проектирование базы данных 

    12.15. Hull R., King R. Semantic Database Modeling: Survey, Applications, 
and Research Issues // ACM Сотр. Surv. — 1987. — 19, № 3. 
    Обширное введение в семантическое моделирование и связанные с ним вопросы. 
Эта статья является прекрасной отправной точкой для изучения семантического 
моделирования и связанных с ним проблем и тем. 
    12.16. Jagannathan D. et al. SIM: A Database System Based on the Semantic 
Data Model // Proc. 1988 ACM SIGMOD Intern. Conf. on Management of Data. — 
Chicago, 111, 1988. Описание коммерческой СУБД на основе семантической модели 
данных, предложенной Хаммером и Мак-Леодом в [12.13]. 
    12.17. Kent W. A Taxonomy of Entity-Relationship Models. — Частное 
сообщение, 1982. 
    12.18. Mannila H., Raiha K.-J. The Design of Relational Databases. — 
Wokingham, UK: Addison-Wesley, 1992. 
    Согласно предисловию эта книга является учебным пособием для студентов и 
библиографическим справочником по вопросам проектирования реляционных баз 
данных. В ней, с одной стороны, описана теория зависимостей и процедура 
нормализации, а с другой — модель объект/отношение, причем в каждом случае 
изложение ведется с формальной точки зрения. Ниже перечислены названия глав из 
этой книги, которые могут дать представление о ее содержании. 
    • Принципы проектирования. 
    • Ограничения целостности и зависимости. 
    • Свойства реляционных схем. 
    • Аксиоматизация зависимостей. 
    • Алгоритмы для задач проектирования. 
    • Отображения между диаграммами объект/отношение и схемами реляционных баз данных. 
    • Преобразования схем. 
    • Примеры проектирования баз данных. 
    Описанные в книге технологии были воплощены ее авторами в виде инструмента 
под названием Design By Example (макет по образцу). 
    12.19. Olle T.W., Sol H.G, Verrijn-Stuart A.A. (eds.). Information Systems 
Design Methodologies: A Comparative Review. — Amsterdam, Netherlands: 
North-Holland; New York, N.Y.: Elsevier Science, 1982. 
    Доклады конференции IFIP Working Group 8.1, в которых описаны 13 различных 
методик и результаты их воплощения для решения стандартной тестовой задачи. В 
книгу также включены обзоры некоторых предложенных подходов. 
    12.20. Peckham J., Maryanski F. Semantic Data Models // ACM Сотр. Surv. — 
1988. — 20, №3. Еще один вводный обзор. 
    12.21. Schmid H. A., Swenson J. R. On the Semantics of the Relational Data 
Base Model // Proc. 1975 ACM SIGMOD Intern. Conf. on Management of Data. — San 
Jose, Calif., 1975. 
    В работе представлена "базовая семантическая модель", которая 
предшествовала работе Чена с описанием модели объект/отношение, но была 
подобна этой модели (конечно, за исключением используемой терминологии, 
поскольку Шмид и Свенсон использовали термины независимый объект, зависимый 
объект и соединение вместо терминов Чена правильный объект, слабый объект и 
отношение соответственно). 
    12.22. Smith J.M.,  Smith  D.C.P.  Database Abstractions:  Aggregation // 
CACM.— 1977.— 20, №6. См. аннотацию к [12.23]. 

    Глава 12. Модель типа объект/отношение	351 

    12.23. Smith J.M., Smith D.C.P. Database Abstractions: Aggregation and 
Generalization // ACM TODS. — 1977. — 2, № 2. 
    Идеи, высказанные в статьях [12.22, 12.23], оказали значительное влияние 
на формулировку модели RM/T [12.5], особенно в области подтипов и супертипов. 
    12.24. Storey V.C. Understanding Semantic Relationships // The VLDB 
Journal. — 1993.—2, №4. 
    В аннотации к статье говорится, что семантические модели данных были 
развиты в сообществе исследователей баз данных с использованием таких 
абстракций, как подтип и агрегация; помимо хорошо известных понятий, некоторые 
дополнительные семантические понятия были созданы исследователями в таких 
дисциплинах, как лингвистика, логика и когнитивная психология. Также 
отмечается, что в статье исследуются некоторые из последних понятий и 
обсуждается их влияние на проектирование баз данных. 
    12.25. Sundgren В. The Infological Approach to Data Bases // J. W. Klimbie 
and K. L. Koffeman (eds.). Data Base Management. — Amsterdam, Netherlands: 
North-Holland; New York, N.Y.: Elsevier Science, 1974. 
    "Информационно-логическим" ("infological") называется подход в 
семантическом моделировании, который долгие годы успешно использовался в Скандинавии. 
    12.26. Tasker D. Fourth Generation Data: A Guide to Data Analysis for New 
and Old Systems. — Sydney, Australia: Prentice-Hall of Australia Pty., Ltd., 1989. 
    Прекрасное практическое пособие по проектированию баз данных, в котором 
внимание главным образом уделяется индивидуальным объектам данных. Объекты 
данных разделены на три основных типа: именные, количественные и описательные. 
Именные обозначают объекты и в реляционном смысле относятся к первичным и 
внешним ключам. Количественные представляют собой меру или расположение 
согласно какой-то шкале (скорее всего, шкале дата/время) и могут быть 
подвергнуты обычным арифметическим манипуляциям. Все остальные объекты 
относятся к описательным. (Конечно, это краткое описание не может дать полного 
представления обо всей классификационной схеме.) В книге подробно обсуждается 
каждый из перечисленных типов объектов. Эти описания не всегда можно назвать 
"чисто реляционными", поскольку, например, использованное Таскером понятие 
"домена" не вполне отвечает реляционному смыслу этого термина. Однако в книге 
содержится достаточно материала, имеющего большое практическое значение. 
    12.27. Teorey T.J., Fry J.P. Design of Database Structures.— Englewood 
Cliffs, N.J.: Prentice-Hall, 1982. 
    Учебник по всем вопросам проектирования баз данных, который разделен на 
пять частей: введение, концептуальное проектирование, практическое 
проектирование (т.е. преобразование концептуального проектирования в 
конструкции, которые можно применить для конкретной СУБД), физическое 
проектирование и вопросы специализированного проектирования. 
    12.28. Teorey T.J., Yang D., Fry J.P. A Logical Design Methodology for 
Relational Databases Using the Extended Entity-Relationship Model // ACM Сотр. 
Surv. — 1986.—18, №2. 
    В представленную в этой работе "расширенную модель объект/отношение" 
добавлена поддержка обобщения и иерархий подмножеств (два варианта иерархий 
типов), обработка пустых значений и отношения, включающие больше двух участников. 
    12.29. Teorey T.J. Database Modeling and Design: The Entity-Relationship 
Approach. — San Mateo, Calif: Morgan Kaufmann, 1990. 
    Более современный учебник с описанием применения концепций модели 
объект/отношение и "расширенной" модели объект/отношение [12.28] для 
проектирования базы данных. 

    352	Часть III. Проектирование базы данных 

