
- •7.7.6. Определить общее количество поставщиков
- •7.7.7. Определить в поставках максимальное
- •7.7.8. Для каждой поставляемой детали указать номер и общий объем поставки в штуках
- •7.7.9. Указать номера всех типов деталей, поставляемых более чем одним поставщиком
- •7.7.10. Определить имена поставщиков детали с номером т2'
- •7.7.11. Определить имена поставщиков по крайней мере одной красной детали
- •7.7.12. Указать номера поставщиков, статус которых меньше текущего максимального статуса
- •7.7.13. Указать имена поставщиков детали с номером 'р2'
- •7.7.14. Выбрать имена поставщиков, которые не поставляют деталь с номером 'р2'
- •7.7.15. Определить имена поставщиков всех типов деталей
- •7.7.16. Определить номера деталей, которые либо весят более 16 фунтов, либо поставляются поставщиком с номером 's2', либо и то, и другое
- •7.8. Резюме
- •8.2. Ограничения типа
- •8.3. Ограничения атрибута
- •8.4. Ограничения переменной-отношения
- •8.5. Ограничения баз данных
- •8.6. "Золотое правило"
- •8.7. Ограничения состояния и ограничения перехода
- •8.8. Ключи
- •3. Пусть r1 и r2 — ссылающаяся и ссылочная переменные-отношения соответственно.
- •8.9. Средства языка sql
- •8.10. Резюме
- •9.1. Введение
- •9.2. Для чего нужны представления
- •9.3. Выборка данных из представлений
- •9.4. Обновление данных в представлениях
- •9.5. Моментальные снимки
- •9.6. Поддержка представлений в языке sql
- •9.7. Резюме
- •Часть III
- •10.1. Введение
- •10.2. Основные определения
- •10.3. Тривиальные и нетривиальные зависимости
- •10.4. Замыкание множества зависимостей
- •10.5. Замыкание множества атрибутов
- •10.6. Неприводимые множества зависимостей
- •10.7. Резюме
- •Глава 1 1
- •I Переменные-отношения в знф I
- •11.2. Декомпозиция без потерь
- •11.3. Первая, вторая и третья нормальные формы
- •11.4. Сохранение зависимостей
- •11.5. Нормальная форма Бойса-Кодда
- •11.6. Замечание по поводу атрибутов, содержащих в качестве значений отношения
- •11.7. Резюме
- •12.1. Введение
- •12.2. Многозначные зависимости и четвертая нормальная форма
- •12.3. Зависимости соединения и пятая нормальная форма
- •Соединение по комбинации атрибутов j#,s#
- •Исходное состояние spj
- •12.4. Общая схема процедуры нормализации
- •12.5. Денормализация
- •12.6. Ортогональное проектирование (небольшое отступление от темы)
- •12.7. Другие нормальные формы
- •12.8. Резюме
- •12.3. Brosda V., Vossen g. Update and Retrieval Through a Universal Schema Interface // acm tods. — December, 1988. — 13, № 4.
- •12.5. Date c.J. Will the Real Fourth Normal Form Please Stand Up? // c. J. Date and Hugh Darwen. Relational Database Writings 1989-1991.— Reading, Mass.: Addison-Wesley, 1992.
- •12.20.Kent w. The Universal Relation Revisited // acm tods. — December, 1983. — 8, № 4.
- •12.22.Maier d., Ullman j.D. Fragments of Relations // Proc. 1983 sigmod Intern. Conf. On Management of Data. — San Jose, Calif. — May, 1983.
- •12.24.Maier d., Ullman j.D. Maximal Objects and the Semantics of Universal Relation Databases // acm tods. — March, 1983. — 8, № 1.
- •Глава 13
- •13.1. Введение
- •13.2. Общий подход
- •Каждыи экземпляр сущности ности «Произведение"
- •13.3. Модель "сущность/связь"
- •13.5. Проектирование базы данных с помощью метода er-моделирования
- •13.6. Краткий анализ er-модели
- •13.7. Резюме
13.2. Общий подход
Общий подход к проблеме семантического моделирования характеризуется четырьмя основными этапами.
1. Прежде всего попытаемся выявить некоторое множество семантических концепций (понятий), которые могут быть полезны при неформальном обсуждении реального мира.
Например, можно согласиться с тем, что мир построен из сущностей. (Хотя невозможно с определенной точностью описать, что именно представляет собой сущность, эта концепция, тем не менее, оказывается весьма полезной для описания реального мира, по крайней мере с интуитивной^ точки зрения.)
Развивая данную концепцию, можно допустить, что сущности могут быть с пользой классифицированы по разным типам сущностей. Например, можно предположить, что каждый отдельный работник является экземпляром некоторого универсального типа сущности с именем EMPLOYEE (работник). Преимущество такой классификации заключается в том, что все сущности определенного типа будут обладать некоторыми общими свойствами (например, все работники получают зарплату), а потому подобная группировка может привес
ти к некоторой (и совершенно очевидной) систематизации представлений. Например, в терминах реляционной теории выявленная общность может быть зафиксирована в заголовке переменной-отношения.
Более того, можно пойти еще дальше и согласиться с тем, что каждая сущность обладает неким особым свойством, предназначенным для ее идентификации, т.е. с тем, что каждая сущность обладает собственной идентичностью.
Наконец, можно также предположить, что каждая сущность может быть связана с другими сущностями посредством некоторых связей.
И т.д. Однако здесь следует заметить, что все эти термины ("экземпляр сущности", "тип сущности", "свойство", "связь" и т.д.) определены не совсем точно или формально, поскольку они являются всего лишь концепциями "реального мира", а не формальными терминами. Таким образом, данный первый этап является неформальным, тогда как приведенные ниже второй, третий и четвертый этапы, напротив, достаточно формальны.
Далее попытаемся определить набор соответствующих символических (т.е. формальных) объектов, которые могут использоваться для представления описанных выше семантических концепций. (Замечание. Здесь термин объект не используется в каком-то строго определенном смысле!) Например, в расширенной реляционной модели (RM/T) [13.6] вводится несколько особых видов отношений, которые называются Е- и Р-отношениями. Грубо говоря, Е-отношения (от "entity-relations") представляют сущности, а Р-отношения (от "property-relations") — свойства, однако Е- и Р-отношения, безусловно, имеют конкретные формальные определения, тогда как сами сущности и свойства их не имеют.
Кроме того, следует определить набор формальных общих правил целостности (или, используя терминологию главы 8, "метаограничений"), предназначенных для работы с такими формальными объектами. Например, RM/T-модель включает правило целостности свойств, которое утверждает, что для каждого элемента Р-отношения должен существовать соответствующий ему элемент в Е-отношении (это отражает тот факт, что каждое свойство в базе данных должно быть свойством некоторой сущности).
Наконец необходимо также определить набор формальных операторов, предназначенных для манипулирования этими формальными объектами. Например, в RM/T-модели присутствует оператор PROPERTY, который можно использовать для соединения Е-отношения со всеми соответствующими ему Р-отношениями независимо от того, сколько их и какие им присвоены имена, т.е. оператор, позволяющий собрать воедино все свойства любой сущности.
Описанные в пп. 2-4 объекты, правила и операторы совместно образуют расширенную модель данных, но только если эти конструкции действительно являются супермножеством конструкций одной из базовых моделей, например такой, как базовая реляционная модель. Однако на самом деле в данном контексте нет четкого различия между тем, что является расширенным, а что является базовым. Обратите особое внимание на то, что правша и операторы являются такой же частью расширенной модели, как и объекты (безусловно, это утверждение справедливо и для базовой реляционной модели). Тем не менее с ''точки зрения проектирования баз данных операторы являются менее
важной частью модели по сравнению с объектами и правилами целостности. Поэтому за исключением нескольких посвященных операторам комментариев основное внимание в этой главе уделяется именно объектам и правилам.
Напомним, что на первом этапе была предпринята попытка выявить множество семантических концепций, которые были бы полезны для описания реального мира. Некоторые из этих концепций, а именно — сущности, свойства, связи и подтипы, представлены в табл. 13.1 с указанием неформального определения и приведением нескольких типичных примеров. Обратите внимание, что все эти специально подобранные примеры иллюстрируют возможность рассмотрения одного и того же объекта реального мира одними пользователями в качестве сущности, другими— в качестве свойства, а третьими — в качестве связи. (Этот пример прекрасно демонстрирует, почему невозможно дать строгое определение такого термина, как "сущность".) Одна из целей семантического моделирования (несомненно, полностью достигнутая) как раз и заключается в поддержке такой гибкости интерпретации.
Таблица 13.1. Некоторые полезные семантические концепции
Понятие Неформальное определение Примеры
СУЩНОСТЬ Некоторый отличимый объект Поставщик, деталь, поставка (Entity) Работник, отдел, человек
Произведение, концерт, оркестр, дирижер
Заказ на поставку, серия заказов
СВОЙСТВО Элемент информации, опиеы- Номер поставщика, поставляемое (Property) вающий сущность количество
Отдел работника, рост человека
Тип концерта
Дата заказа
СВЯЗЬ Сущность, которая служит для Поставка (поставщик — деталь)
(Relationship) обеспечения взаимодействия должность (работник - отдел) между двумя или более други- ми сущностями Запись (произведение — оркестр —
дирижер)
ПОДТИП Сущность типа Y является "Работник" является подтипом (Subtype) подтипом сущности типа X сущности "Человек"
тогда и только тогда, когда «Концерт» является подтипом сущ-