- •Isbn 5-8459-0138-3 (рус) isbn 0-201-38590-2 (англ)
- •Глава 2. Архитектура системы баз данных 65
- •Глава 6. Реляционная алгебра 192
- •Глава 7. Реляционное исчисление 243
- •Глава 8. Целостность данных 301
- •Глава 9. Представления 350
- •Часть 111
- •Часть IV
- •Глава 14. Восстановление 544 14.1. Введение 544
- •Глава 15. Параллельность 566
- •Часть V
- •Глава 16. Защита данных 602
- •Глава 17. Оптимизация 639
- •Глава 18. Отсутствующая информация 693
- •Глава 19. Наследование типов 725
- •Глава 20. Распределенные базы данных 767
- •Глава 21. Поддержка принятия решений 813
- •Глава 22. Хронологические базы данных 853
- •Глава 23. Логические системы управления базами данных 899
- •Часть VI
- •Глава 24. Объектные базы данных 944
- •Глава 25. Объектно-реляционные базы данных 999
- •Часть I (четыре главы) — это обширное введение в теорию баз данных вообще и реляционных баз данных в частности. Здесь также излагаются основы стандартно- го языка баз данных sql.
- •Часть IV. Две главы данной части — это несколько пересмотренные и расширен- ные версии глав 13 и 14 предыдущего издания.
- •Часть VI. Глава 24 является полностью переписанной и значительно улучшенной версией глав 22-24. Глава 25 почти полностью обновлена.
- •Часть I
- •Часть I состоит из четырех вводных глав.
- •1.1. Вводный пример
- •1.2. Что такое система баз данных
- •1.3. Что такое база данных Перманентные данные
- •1.4. Назначение баз данных
- •1.5. Независимость данных
- •1.6. Реляционные и другие системы
- •1.7. Резюме
- •2.1. Введение
- •2.2. Три уровня архитектуры
- •Внешний уровень (представления отдельных пользователей)Концептуальный уровень (обобщенное представление пользователей)
- •2.3. Внешний уровень
- •Отображение "внешний/концептуальный" схемы
- •Определение структур хранения (внутренняя схема)
- •Внешнее представление а Концептуальная схема
- •2.4. Концептуальный уровень
- •2.5. Внутренний уровень
- •2.6. Отображения
- •2.7. Администратор базы данных
- •2.8. Система управления базой данных
- •2.9. Система управления передачей данных
- •2.10. Архитектура "клиент/сервер"
- •2.11. Утилиты
- •2.12. Распределенная обработка
- •2.13. Резюме
- •3.1. Введение
- •3.2. Реляционная модель
- •3.3. Отношения и переменные-отношения
- •3.4. Смысл отношений
- •3.5. Оптимизация
- •3.6. Каталог
- •3.7. Базовые переменные-отношения и представления
- •3.8. Транзакции
- •3.9. База данных поставщиков и деталей
- •3.10. Резюме
- •Глава 4
- •4.1. Введение
- •4.2. Обзор языка sql
- •4.3. Каталог
- •4.4. Представления
- •4.5. Транзакции
- •4.6. Внедрение sql-операторов
- •4.7. Несовершенство языка sql
- •4.8. Резюме
- •Часть 9. Управление внешними данными (sql/med) Часть 10. Связь с объектным языком (sql/olb)
- •Часть II
- •Глава 5
- •5.1. Введение
- •5.2. Домены
- •5.3. Значения отношений
- •5.4. Переменные-отношения
- •5.5. Средства sql
- •5.6. Резюме
- •6.1. Введение
- •6.2. Реляционная замкнутость
- •6.3. Синтаксис
- •6.4. Семантика
- •6.5. Примеры
- •6.5.1. Получить имена поставщиков детали с номером 'р2'
- •6.5.2. Получить имена поставщиков по крайней мере одной красной детали
- •6.5.3. Получить имена поставщиков всех типов деталей
- •6.5.4. Получить номера поставщиков по крайней мере тех типов деталей, которые поставляет поставщик с номером 's2'
- •6.5.5. Получить все пары номеров поставщиков, находящихся в одном городе
- •6.5.6. Получить имена поставщиков, которые не поставляют деталь с номером 'р2'
- •6.6. Зачем нужна реляционная алгебра
- •6.7. Дополнительные операторы
- •6.8. Группирование и разгруппирование
- •6.9. Реляционные сравнения
- •6.10. Резюме
- •7.1. Введение
- •7.2. Исчисление кортежей
- •7.3. Примеры
- •7.3.5. Найти имена поставщиков по крайней мере одной детали, поставляемой поставщиком с номером 's2'
- •7.3.6. Выбрать имена поставщиков всех типов деталей
- •7.3.7. Определить имена поставщиков, которые не поставляют деталь с номером 'р2'
- •7.3.8. Определить номера поставщиков по крайней мере всех типов деталей, поставляемых поставщиком с номером *s2'
- •7.4. Сравнительный анализ реляционного исчисления и реляционной алгебры
- •7.5. Вычислительные возможности
- •7.5.1. Определить номера и вес в граммах всех типов деталей, вес которых превышает 10 ооо г
- •7.6.1. Выбрать номера поставщиков из Парижа со статусом, большим 20
- •7.7.1. Указать цвета деталей и названия городов, в которых находятся детали "не из Парижа" с весом, превышающим 10 фунтов
- •7.7.2. Для всех деталей указать номер и вес в граммах
- •7.7.3. Выбрать информацию обо всех парах поставщиков и деталей, находящихся в одном городе
- •7.7.4. Найти все пары названий городов, таких, что поставщик из первого города поставляет деталь, находящуюся во втором городе
- •7.7.5. Выбрать все пары номеров поставщиков, таких, что оба поставщика в каждой паре находятся
3.4. Смысл отношений
В главе 1 отмечалось, что столбцы в отношениях связаны с типами данных2. А в конце раздела 3.2 мы говорили, что реляционная модель включает "неограниченный на- бор типов [данных]". Помимо всего прочего, это означает, что пользователи могут оп- ределять собственные типы (а также, конечно, применять определенные системой или встроенные типы). Например, определять типы можно представленным ниже способом (снова воспользуемся синтаксисом языка Tutorial D, причем многоточие здесь за- меняет определения, которые для нас сейчас не важны).
TYPE EMPi ... ; TYPE NAME ... ; TYPE DEPTi ... ; TYPE MONEY ... ;
Тип EMPi, например, можно рассматривать, как множество всевозможных номеров служащих, тип NAME — как множество всевозможных имен, и т.д.
Как
мы увидим в главе 5, для типов данных
чаще используют термин "домены ".
Рис. 3.4. Пример значения отношения ЕМР с отображением типов столбцов
Замечание. На практике компоненты заголовка "имя-тип" зачастую опускают, как это делали и мы во всех предыдущих примерах. Однако необходимо учитывать, что концеп- туально они всегда присутствуют.
Рассмотрим один важный, хотя и не столь распространенный, способ представления смысла отношений.
Во-первых, данное отношение г и заголовок отношения г представляют опреде- ленный предикат или логическую функцию.
Во-вторых, как упоминалось в главе 1, каждая строка в теле отношения г представ- ляет собой определенное истинное высказывание, полученное из предиката путем подстановки определенных значений аргументов соответствующего типа вместо местодержателей или параметров этого предиката (реализация предиката).
Например в случае, представленном на рис. 3.4, предикат будет следующим.
Служащий с номером EMPi по фамилии ENAME работает в отделе с номером DEPTt и получает зарплату SALARY.
Здесь параметрами являются EMPt, ENAME, DEPTt и SALARY, которые, конечно же, соот- ветствуют четырем столбцам переменной-отношения ЕМР. Вот примеры соответствую- щих истинных утверждений.
Служащий с номером 'El' по фамилии 'Lopez' работает в отделе с номером 'Dl' и получает зарплату 40 тыс. долларов в год.
(Получено путем подстановки в параметр EMPi значения ' Е1', в параметр NAME — зна- чения ' Lopez', в параметр DEPTt — значения ' D1' ив параметр SALARY — значения 40К.)
Служащий с номером 'Е2' по фамилии 'Cheng' работает в отделе с номером 'D1' и получает зарплату 42 тыс. долларов в год.
(Получено путем подстановки в параметр EMPt значения 'Е2', в параметр NAME — значения 'Cheng', в параметр DEPTt — значения 'Dl' ив параметр SALARY — значения 42К.) Короче говоря:
типы — это объекты (множества объектов), которые можно обсуждать;
отношения — это факты (множества фактов), касающиеся объектов, кото- рые можно обсуждать.
(Есть прекрасная аналогия, которая может помочь вам понять смысл и запомнить эти важные определения: Типы связаны с отношениями точно так, как существительные связаны с предложениями.) В нашем примере то, что мы можем обсуждать, — это номе- ра служащих, их имена, номера отделов и значения денежных сумм, а то, что мы можем
сказать об обсуждаемом, — это истинное высказывание такого вида: "Служащий с опре- деленным номером служащего имеет определенное имя, работает в определенном отделе и получает определенную зарплату". Из вышесказанного следует, что:
во-первых, необходимы и типы, и отношения (без типов нам не о чем говорить, без отношений мы ничего не сможем сказать);
во-вторых, типы и отношения достаточны так же, как и необходимы, т.е., логи- чески говоря, нам не нужно что-либо еще.
Замечание. Также можно сделать вывод о том, что типы и отношения — это не одно и то же. К сожалению, в некоторых коммерческих продуктах (нереляционных по опре- делению!) эти два понятия смешиваются. Мы еще вернемся к данному вопросу в гла- ве 25 (раздел 25.2).
Кстати, важно понимать, что каждое отношение имеет связанный с ним предикат, включая отношения, полученные с помощью реляционных операторов, например опера- тора соединения. Отношение DEPT на рис. 3.1 и три результирующих отношения на рис. 3.2 имеют такие предикаты.
DEPT: "Отдел с номером DEPTi называется DNAME и имеет бюджет BUDGET".
Выборка строк из DEPT, где BUDGET > 8М: "Отдел с номером DEPTi называется DNAME и имеет бюджет BUDGET, который больше восьми миллионов долларов".
Извлечение столбцов DEPTt и BUDGET из DEPT: "Отдел с номером DEPTf имеет ка- кое-то название и бюджет BUDGET".
Соединение переменных-отношений DEPT и ЕМР на основе столбца DEPTi: "Отдел с номером DEPTt называется DNAME и имеет бюджет BUDGET, а служащий с номером EMPt по фамилии ENAME работает в отделе с номером DEPTi и получает зарплату SALARY" (заметим, что этот предикат имеет шесть параметров, а не семь, посколь- ку две ссылки на DEPTt обозначают один и тот же параметр).