Новое издание фундаментального труда Криса Дейта "Введение в системы баз данных" представляет собой исчерпывающее введение в очень обширную в настоящее время теорию систем баз данных. С помощью этой книги читатель сможет приобрести фундаментальные знания в области технологии баз данных, а также ознакомиться с направлениями, по которым рассматриваемая сфера деятельности, вероятно, будет развиваться в будущем. Книга предназначена для использования в основном в качестве учебника, а не справочника, поэтому, несомненно, вызовет интерес у программистов-профессионалов, научных работников и студентов, изучающих соответствующие курсы в высших учебныхзаведениях. В ней сделан акцент на усвоении сути и глубоком понимании излагаемого материала, а не просто на его формальном изложении. Книга "Введение в системы базданных", безусловно, будет полезна всем, кому приходится работать с базами данных или просто пользоваться ими.

Издательство: "Вильямс" (2016)

Формат: 70x100/16, 1328 стр.

ISBN: 978-5-8459-0788-2, 0-321-19784-4

На Озоне

Отзывы о книге:

Достоинства: Очень подробно про реляционную модель данных, местами даже чересчур подробно. Недостатки: Честно говоря, не совсем то что я ожидал. Каких-то алгоритмических находок которые можно было бы использовать при создании новой СУБД очень немного, привязки к уже существующим СУБД тоже практически нет. Советов в конструировании эффективных запросов или в построении моделей данных тоже нет. Итого, это скорее такой труд, описывающий теорию построения СУБД (что вот есть данные, а вот еще есть отношения, и куча интуитивно-понятных операций с ними). Список литературы в конце каждой главы иногда по размеру сопоставим с самой главой. Очень много воды, возможно поэтому книжка размером в 1300 страниц. Отдельно разочарован главой про транзакции, которым уделено всего 20 страничек, и весьма поверхностно. В то же время картинка поясняющая что такое пересечение, объединение или разница (на примитивном примере пересекающихся прямоугольников) может занимать почти всю страницу. Комментарий: Поставил три звезды только из уважения к автору за титанический труд объединить и разложить по главам все что известно про СУБД. Практический смысл в этой книге невелик, теория тут расписана весьма неравномерно, где-то будем жевать что такое отображение на сотнях страниц, а где-то про рекурсивный поиск все уместим в два предложения.

Stepanov Sergey0

В целом книга представляет собой огромный академический труд гуру по реляционным базам данных. Концепция данной монографии хорошо продумана: все изложено последовательно, с постепенным усложнением материала. В начале автор излагает математические основы реляционных систем, базовые понятия и определения. Если их не усвоить с самого начала, то потом беседовать с автором будете на разных языках. Кроме изложения всех основных моментов, в книге присутствуют детальные примеры использования описанных выше теоретических подходов. Все разобрано достаточно четко, нужно просто много думать. Как и в любой монографии крупного специалиста, в книге присутствует личное мнение автора, которое всегда аргументируется, но не всегда, на мой взгляд, бесспорно. Особенно это касается объектного подхода к базам данных. Лично мне показалось, что книга написана скорее для будущих разработчиков систем управления баз данных, чем для администраторов, например. Автор детально разбирает все операции, которые происходят под покровом запросов, опираясь на реляционную модель. Из плюсов книги можно отметить адекватный перевод, большое количество заданий разного уровня сложности, огромный список дополнительной литературы по всем затронутым вопросам. К минусам я бы отнес академичность изложения и достаточно высокую сложность изложенного материала. Я совсем не сторонник разжевывания каждой детали, но предварительная база в области теории множеств и исчисления предикатов намного упростит понимание материала. Мне очень помогли мои университетские курсы. Я рекомендую книгу для покупки тем, кто очень хочет реально понять внутренние механизмы баз данных, готов потратить значительное время на изучение вопроса и имеет пытливый ум.

Денис, 29, Екатеринбург

Другие книги схожей тематики:

    Автор Книга Описание Год Цена Тип книги
    Дейт К. Дж. Новое издание фундаментального труда Криса Дейта "Введение в системы баз данных" представляет собой исчерпывающее введение в очень обширную в настоящее время теорию систем баз данных. С помощью этой… - Диалектика, (формат: 70x100/16, 1328 стр.) 2019
    		6657 бумажная книга
    К. Дж. Дейт Новое издание фундаментального труда Криса Дейта "Введение в системы баз данных" представляет собой исчерпывающее введение в очень обширную в настоящее время теорию систем баз данных. С помощью этой… - Вильямс, (формат: 70x100/16, 1328 стр.) 2016
    		3291 бумажная книга
    К. Дж. Дейт Новое издание фундаментального труда Криса Дейта представляет собой исчерпывающее введение в очень обширную в настоящее время теорию систем баз данных. С помощьюэтой книги читатель сможет приобрести… - Вильямс, (формат: 70x100/16, 1328 стр.) 2006
    		3053 бумажная книга
    Крис Дейт От издателя:8-е издание фундаментального труда Криса Дейта представляет собой исчерпывающее введение в очень обширную в настоящее время теорию систем баз данных - (формат: 70x100/16 (~170х240 мм), 1328стр. (таблицы, схемы) стр.) 2008
    		1254 бумажная книга
    Гради Буч Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль… - ДМК Пресс, Классика программирования электронная книга
    		479 электронная книга
    Гради Буч Введение в UML от создателей языка Эта книга будет изготовлена в соответствии с Вашим заказом по технологии Print-on-Demand. Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для… - ДМК Пресс, - 2010
    		618 бумажная книга
    Введение в UML от создателей языка Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль… - ДМК-Пресс, Классика программирования 2015
    		1031 бумажная книга
    Буч Г., Рамбо Д., Якобсон И. Введение в UML от создателей языка 496 с. Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая… - ДМК, (формат: 70x100/16, 1328 стр.) Классика программирования 2011
    		799 бумажная книга
    Гради Буч, Джеймс Рамбо, Ивар Якобсон Введение в UML от создателей языка Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль… - ДМК Пресс, (формат: 70x100/16, 1328 стр.) Классика программирования 2012
    		799 бумажная книга
    Рамбо Джеймс, Якобсон Ивар, Буч Гради Введение в UML от создателей языка Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль… - ДМК Пресс, (формат: 70x100/16, 496 стр.) Классика программирования 2015
    		1106 бумажная книга
    Переиздана книга «Введение в системы баз данных », Крис Дж. Дейт , 8 -е издание, бумага офсетная -белая, твердый переплет , 1328 стр., ISBN 978-5-8459-0788-2, «ВИЛЬЯМС», 2016 - заказать-купить книгу «» в интернет-магазине ComBook.ru

    Восьмое издание фундаментального труда «Введение в системы баз данных » Криса Дейта представляет собой исчерпывающее введение в очень обширную в настоящее время теорию систем баз данных

    С помощью этой классической книги читатель сможет приобрести фундаментальные знания в области технологии баз данных, а также ознакомиться с направлениями, по которым рассматриваемая сфера деятельности, вероятно, будет развиваться в будущем

    Книга «Введение в системы баз данных » предназначена для использования в основном в качестве учебника, а не справочника, поэтому, несомненно, вызовет интерес у программистов-профессионалов, научных работников и студентов, изучающих соответствующие курсы в высших учебных заведениях

    В книге Криса Дейта сделан акцент на усвоении сути и глубоком понимании излагаемого материала, а не просто на его формальном изложении

    Книга «Введение в системы баз данных », безусловно, будет полезна всем, кому приходится работать с базами данных или просто пользоваться ими

    ( )
    (заказать-купить книгу «Введение в системы баз данных » в интернет-магазине ComBook.ru )

    ( )
    (заказать-купить книгу по «Введение в системы баз данных » в онлайн-мегамаркете Ozon.ru )

    ( )
    (заказать-купить книгу «Введение в системы баз данных » в интернет-магазине diamail.com.ua )

    На русском языке книга вышла в июле 2016 года в издательстве «ВИЛЬЯМС » и допечатана ограниченным тиражом

    ОГЛАВЛЕНИЕ книги «Введение в системы баз данных » (8 -е издание )
    ____________________________________
    Введение

    Часть I. Основные понятия
    Глава 1. Базы данных и управление ими
    Глава 2. Архитектура системы баз данных
    Глава 3. Введение в реляционные базы данных
    Глава 4. Введение в язык SQL

    Часть II. Реляционная модель
    Глава 5. Типы
    Глава 6. Отношения
    Глава 7. Реляционная алгебра
    Глава 8. Реляционное исчисление
    Глава 9. Целостность данных
    Глава 10. Представления

    Часть III. Проектирование базы данных
    Глава 11. Функциональные зависимости
    Глава 12. Дальнейшая нормализация: формы 1нф, 2нф, 3нф и нфбк
    Глава 13. Дальнейшая нормализация: нормальные формы более высокого порядка
    Глава 14. Семантическое моделирование

    Часть IV. Управление транзакциями
    Глава 15. Восстановление
    Глава 16. Параллельность

    Часть V. Дополнительные темы
    Глава 17. Защита данных
    Глава 18. Оптимизация
    Глава 19. Отсутствующая информация
    Глава 20. Наследование типов
    Глава 21. Распределенные базы данных
    Глава 22. Поддержка принятия решений
    Глава 23. Хронологические базы данных
    Глава 24. Логические системы управления базами данных

    Часть VI. Объекты, отношения и язык XML
    Глава 25. Объектные базы данных
    Глава 26. Объектно-реляционные базы данных
    Глава 27. World Wide Web и XML

    Часть VII. Приложения
    Приложение A. Модель TransRelational
    Приложение Б. Выражения SQL
    Приложение В. Сокращения и специальные символы
    Приложение Г. Структуры хранения и методы доступа
    Предметный указатель


    Базы данных.
    Проектирование,
    реализация и
    сопровождение
    Теория и практика

    Томас Коннолли
    Каролин Бегг
    Переиздана книга «Базы данных. Проектирование, реализация и сопровождение. Теория и практика », Томас Коннолли , Каролин Бегг , бумага офсетная -белая, твердый переплет , 1440 стр., ISBN 978-5-8459-2020-1, «ДИАЛЕКТИКА», 2017 - заказать-купить книгу «Базы данных » в интернет-магазине ComBook.ru

    На страницах книги « » сконцентрирован многолетний богатый опыт разработки баз данных для нужд промышленности, бизнеса и науки, а также обучения студентов. Результатом труда Томаса Коннолли и Каролин Бегг стало это полное справочное руководство по проектированию, реализации и сопровождению баз данных

    Книга «Базы данных. Проектирование, реализация и сопровождение. Теория и практика » содержит подробное описание особенностей разработки приложений баз данных для Интернет и многочисленные примеры кода доступа к базам данных из Интернет, в том числе с применением средств JDBC, SQLJ, ASP, JSP и PSP Oracle

    В книге «Базы данных. Проектирование, реализация и сопровождение. Теория и практика » дано всестороннее введение в технологию информационной проходки, хранилищ данных и OLAP, представлены современные распределенные, объектно-ориентированные и объектно-реляционные СУБД

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

    Оригинал книги : «Database Systems: A Practical Approach to Design, Implementation and Management » by Thomas Connolly and Carolyn Begg

    (книгу можно заказать-купить в Библио-Глобус )
    (заказать-купить книгу «Базы данных » в интернет-магазине biblio-globus.ru )

    (книгу можно заказать в КОМБУК е - самая низкая цена в России! )
    (заказать-купить книгу «Базы данных » в интернет-магазине ComBook.ru )

    (книгу можно заказать в Ozon.ru )
    (заказать-купить книгу по «Введение в системы баз данных » в онлайн-мегамаркете Ozon.ru )

    (книгу можно заказать в DiaMail Украина )
    (заказать-купить книгу «Базы данных » в интернет-магазине diamail.com.ua )

    В книге « » даются простые и практические ответы на вопросы, требующие быстрого решения. Проработав 30 уроков , длительностью около 10 минут каждый, вы научитесь всему, что требуется знать, чтобы выгодно пользоваться языком T-SQL для работы с РСУБД Microsoft SQL Server

    Этот удобный карманный справочник начинается с простых примеров извлечения данных и постепенно переходит к более сложным вопросам, включая соединения, подзапросы, регулярные выражения и полноценный текстовый поиск, хранимые процедуры, курсоры, триггеры, табличные ограничения, обработку данных в форматах XML и JSON и многое другое

    Для удобства изучения материала уроков книга «Язык T-SQL для Microsoft SQL Server за 10 минут » снабжена следующими врезками:

    - Совет . Указывает краткие пути и решения практических задач
    - Предупреждение . Помогает избежать типичных скрытых препятствий
    - Примечание . Поясняет сопутствующие понятия и предоставляет дополнительные сведения

    Потратив 10 минут на каждый урок , вы научитесь следующему:

    Пользоваться T-SQL SQL Server
    - Составлять сложные запросы, используя операторы, предложения и операции на T-SQL
    - Извлекать, сортировать и форматировать содержимое базы данных


    - Внедрять глобализацию и локализацию на SQL Server
    - Составлять подзапросы для уточнения данных
    - Автоматизировать рабочую нагрузку с помощью триггеров

    - Обращаться с представлениями, хранимыми процедурами, курсорами, и прочими средствами SQL Server

    (книгу можно заказать-купить в КОМБУК е - самая низкая цена в России! )
    (заказать-купить книгу «Язык T-SQL для Microsoft SQL Server за 10 минут » в интернет-магазине ComBook.ru )

    (книгу можно заказать-купить в Ozon.ru )
    (заказать-купить книгу по «Язык T-SQL для Microsoft SQL Server за 10 минут » в онлайн-мегамаркете Ozon.ru )

    (книгу можно заказать-купить в DiaMail Украина )
    (заказать-купить книгу «Язык T-SQL для Microsoft SQL Server за 10 минут » в интернет-магазине diamail.com.ua )

    В книге « » представлены теоретические основы организации систем больших данных и поясняется, каким образом они воплощаются на практике

    В книге «Большие данные » рассматривается лямбда-архитектура , предназначенная для построения подобных систем, и на примере конкретного веб-приложения поясняются особенности реализации всех уровней этой архитектуры с помощью инструментальных средств вроде Hadoop , Cassandra и Storm

    На основе реалистического примера в книге «Большие данные » изложена теория больших систем передачи и обработки данных, а также показаны практические способы их реализации, развертывания и управления

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

    Книга «Большие данные: принципы и практика построения масштабируемых систем обработки данных в реальном времени » научит Вас создавать большие системы передачи и обработки данных, используя архитектуру, специально разработанную для сбора и анализа данных веб-масштаба. В книге описан масштабируемый, легкий для понимания подход Lambda Architecture , который может быть реализован малочисленной командой. В ней рассмотрена теория больших систем передачи и обработки данных и показано, как их реализовать на практике. Кроме общих принципов обработки больших данных, Вы изучите конкретные технологии, такие как Hadoop , Storm и базы данных NoSQL

    Введение в системы больших данных
    Обработка данных веб-масштаба в реальном времени
    Инструменты Hadoop , Cassandra и Storm
    Расширение опыта использования традиционных баз данных

    От читателей книги «Большие данные: принципы и практика построения масштабируемых систем обработки данных в реальном времени » не требуются знания методов анализа больших данных или владение инструментами NoSQL . Желательно знание основ традиционных баз данных (СУБД )

    Книга «Большие данные » рассчитана на читателей, стремящихся освоить принципы построения систем больших данных и внедрить их на практике

    (книгу можно заказать в КОМБУК е - самая низкая цена в России! )
    (заказать-купить книгу «Большие данные » в интернет-магазине ComBook.ru )

    (книгу можно заказать в Ozon.ru )
    (заказать-купить книгу по «Большие данные » в онлайн-мегамаркете Ozon.ru )

    (книгу можно заказать в DiaMail Украина )
    (заказать-купить книгу «Большие данные » в интернет-магазине diamail.com.ua )

    Третье издание бестселлера Томаса Кайта « », известного во всем мире профессионала Ask Tom , посвящено наилучшим методикам применения СУБД Oracle для построения масштабируемых приложений, которые обладают хорошей производительностью и надежностью

    Философия Тома проста: СУБД Oracle можно воспринимать как «черный ящик» с данными внутри, или же разобраться в том, как она работает, и эксплуатировать СУБД как мощную вычислительную среду. Избрав второй подход, вы обнаружите, что существует не так уж много проблем управления информацией, которые не удалось бы решить быстро и элегантно

    Полностью пересмотренное третье издание книги «Oracle для профессионалов: архитектура, методики программирования и основные особенности версий 9i, 10g, 11g и 12c » покрывает новые приемы разработки, появившиеся в последней версии Oracle Database . Изучение каждого средства производится на основе примеров, при этом объясняется не только то, что оно собой представляет, но также и то, как средство работает, как разрабатывать программное обеспечение с его использованием, и какие известные "подводные камни " с ним связаны

    (книгу можно заказать в Ozon.ru )
    (заказать-купить книгу «Oracle для профессионалов » в онлайн-мегамаркете Ozon.ru )

    (книгу можно заказать в DiaMail Украина )
    (заказать-купить книгу «Oracle для профессионалов » в интернет-магазине diamail.com.ua )

    (книгу можно заказать в bizbook.ua Украина )
    (заказать-купить книгу «Oracle для профессионалов » в интернет-магазине bizbook.ua )

    В книге «SQL: полное руководство » содержится исчерпывающее, глубокое и детальное описание языка SQL . Предназначена она как для пользователей, программистов и специалистов в области обработки данных, так и для менеджеров, которые хотят узнать, какое влияние оказывает SQL на компьютерный рынок

    Книга «SQL: полное руководство » Джеймса Р. Гроффа и др. расскажет Вам, как работать с командами и инструкциями SQL , создавать и настраивать реляционные базы данных, загружать и модифицировать объекты баз данных, выполнять мощные запросы, повышать производительность и выстраивать систему безопасности. Вы узнаете, как использовать инструкции DDL и применять API , интегрировать XML и сценарии Java , использовать объекты SQL , создавать веб-серверы, работать с удаленным доступом и выполнять распределенные транзакции

    В этой книге вы найдете такие сведения, как описания работы с базами данных в памяти, потоковыми и встраиваемыми базами данных, базами данных для мобильных устройств, и многое другое. Книга «SQL: полное руководство » включает полное описание синтаксиса соединений SQL и прочитав эту книгу Вы узнаете:

    Построение SQL-реляционных баз данных и приложенийn Создание, загрузка и модификация объектов баз данных с применением SQL
    - Построение и выполнение простых, многотабличных и суммирующих запросов
    - Реализация системы безопасности с использованием аутентификации, привилегий, ролей и представлений
    - Оптимизация, резервное копирование, восстановление и репликация баз данных
    - Работа с хранимыми процедурами, функциями, расширениями, триггерами и объектами
    - Расширенная функциональность с применением API, динамического и встраиваемого SQL
    - Описание таких вопросов, как транзакции, механизмы блокировок, материализованные представления и протокол двухфазного завершения транзакции
    - Последние тенденции рынка и будущее SQL

    Книга «SQL: полное руководство » включает полное описание возможностей SQL, стандарта ANSI, вопросов применения и программирования. Включает историю, рыночные тенденции и сравнение возможностей ведущих СУБД. Обновленная информация о XML, корпоративных и специализированных базах данных (базы данных в памяти, потоковые и встраиваемые базы данных). Материал от трех ведущих экспертов - Джеймс Р. Грофф, Пол Н. Вайнберг, Эндрю Дж. Оппель, охватывает все аспекты SQL. Пересмотренное с учетом последних версий реляционных СУБД, книга «SQL: полное руководство » поясняет, как создавать, наполнять и администрировать высокопроизводительные базы данных и разрабатывать мощные и надежные приложения с использованием SQL

    (книга есть на складе в КОМБУК е - самая низкая цена в России )
    (заказать-купить книгу по «SQL: полное руководство » в интернет-магазине ComBook.ru )

    ( )
    (заказать-купить книгу по «SQL: полное руководство » в интернет-магазине ozon.ru )

    (книга есть на складе в DiaMail Украина )
    (заказать-купить книгу по «SQL: полное руководство » в интернет-магазине diamail.com.ua )

    Книга «SQL за 10 минут » поможет вам в кратчайшие сроки освоить SQL — самый популярный язык запросов к базам данных. Начиная с простых запросов на выборку данных, автор шаг за шагом рассматривает все более сложные темы, такие как использование операций объединения, подзапросы, хранимые процедуры, индексы, триггеры и ограничения

    Проработав все 22 урока из книги, на каждый из которых придется затратить не более 10 минут , вы узнаете обо всем, что необходимо для практического применения SQL

    Благодаря книге «SQL за 10 минут » вы быстро научитесь самостоятельно составлять запросы к базам данных на языке SQL без чьей-либо помощи

    Примеры, приведенные в книге «SQL за 10 минут », будут работать во всех наиболее популярных СУБД последних версий — IBM DB2 , Microsoft Access , Microsoft SQL Server , MySQL , Oracle , PostgreSQL , SQLite , MariaDB и Apache Open Office Base

    (книга есть на складе в ОЗОН е )
    (заказать-купить книгу по «SQL за 10 минут » в интернет-магазине ozon.ru )

    Книгу «Oracle PL/SQL за 10 минут » в онлайн-мегамаркете Ozon.ru

    В книге «Oracle PL/SQL за 10 минут » даются простые и практические ответы на вопросы, требующие быстрого решения. Этот краткий справочник состоит из 26 уроков. Потратив не более 10 минут на каждый (или даже меньше! ), вы научитесь всему, что требуется знать, чтобы выгодно пользоваться языком PL/SQL при работе с СУБД Oracle

    «Oracle PL/SQL за 10 минут » - очень компактный и удобный карманный справочник, который начинается с простых примеров извлечения данных и постепенно переходит к более сложным вопросам, включая соединения, подзапросы, регулярные выражения и полноценный текстовый поиск, хранимые процедуры, курсоры, триггеры, табличные ограничения и многое другое

    Особенности книги «Oracle PL/SQL за 10 минут »:

    * Простой и удобный для усвоения способ изложения материала, указывающий краткий путь и решения практических задач с демонстрацией на конкретных примерах применения языка PL/SQL и инструментальных средств Oracle

    * Пошаговые инструкции, помогающие избежать типичных скрытых препятствий, просто и доходчиво поясняющие, каким образом в языке PL/SQL работать с представлениями, хранимыми процедурами, курсорами, триггерами и прочими средствами

    *Простое и логичное разъяснение сопутствующих понятий и изложение дополнительного материала

    Изучив книгу «Oracle PL/SQL за 10 минут », Вы научитесь:

    Пользоваться PL/SQL в средах и инструментальных средствах Oracle
    - Составлять сложные запросы, используя операторы, предложения и операции PL/SQL
    - Извлекать, сортировать и форматировать содержимое базы данныхм
    - Отбирать нужные данные, применяя различные способы их фильтрации
    - Применять функции обработки символьных строк, даты и времени, а также математические функции для манипулирования данными
    - Соединять вместе две таблицы и больше
    - Вводить, обновлять и удалять данные
    - Создавать и изменять таблицы базы данных
    - Обращаться с представлениями, хранимыми процедурами, курсорами, триггерами и прочими средствами

    Оригинал книги : « », Ben Forta , 288 pages, ISBN 9780672328664, 2015

    Книга «SQL для чайников » (8 -е издание ) предназначена для тех, кто хочет повысить свой уровень работы с базами данных с помощью языка структурированных запросов — SQL . Вы освоите основы реляционных баз данных и языка SQL , научитесь проектировать базы данных, заполнять их информацией и извлекать ее, используя расширенные возможности языка

    Отдельные части книги «SQL для чайников » посвящены вопросам защиты информации в базах данных и обработки ошибок. Язык SQL не прост, но как только вы приобретаете навыки работы с ним, вы сможете создавать реляционные базы данных и с легкостью извлекать из них ценную информацию

    Используя новейшую версию языка SQL:2011 , вы сможете структурировать систему управления базами данных, реализовать проекты, защищать свои данные, организовывать доступ и работу с ними, обслуживать базу данных и многое другое
    ), п о л н о ц в е т н о е издание , твердый переплет, ~800 стр., ISBN , «ДИАЛЕКТИКА», 2019

    Книга «Компьютерные науки. Базовый курс » написана для студентов, выбравших компьютерные науки своей профессией, а также для студентов, специализирующихся в любых других дисциплинах. Широкий охват материала вместе с четким изложением делает его доступным для студентов с любым базовым уровнем, обеспечивая практическое и реалистичное понимание предмета

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

    Оригинал книги : «Computer Science: An Overview », Glenn Brookshear , Dennis Brylow , 13 th Edition, 736 pages, ISBN 9780134875460, March 2018

    Книга обсуждается в моего блога

    СЛЕДИТЕ ЗА ИЗМЕНЕНИЯМИ В ЭТОМ СООБЩЕНИИ -
    последнее обновление - 30 июля 2018 года
    _______________________________________
    ВОПРОС - какие еще книги этой тематики Вы можете предложить для оперативного издания на русском языке ?

    P .S . Только Ваша активная позиция в столь непростое время будет способствовать появлению новых и нужных Вам книг. А также, способствовать повышению качества книг, издаваемых издательской группой «ДИАЛЕКТИКА -ВИЛЬЯМС »

    _____________________________________________
    Ваши комментарии перед публикацией я просматриваю. Поэтому, я оставляю за собой право публиковать или нет комментарии с подписью Анонимный

    Функции СУБД Дейт, К. Дж. Введение в системы базы данных [текст]/ К. Дж. Дейт. - М.: изд-во Вильямс, 2006. - 1328 с. - ISBN 5-5489-0788-8.

    Более точно, к числу функций СУБД принято относить следующие:

    ¦ Определение данных

    СУБД должна предоставлять средства определения данных в виде исходной формы и преобразования этих определений в соответствующую объектную форму. Иначе говоря, СУБД должна включать в себя компоненты процессора ЯОД (языка определения данных) или компилятора ЯОД для каждого из поддерживаемых ею языков определения данных. СУБД должна также правильно трактовать синтаксис языка определения данных, чтобы ей можно было, например, сообщить, что внешние записи EMPLOYEE включают поле SALARY. Эту информацию СУБД должна использовать при анализе и выполнении запросов обработки данных.

    ¦ Манипулирование данными

    СУБД должна быть способна обрабатывать запросы пользователя на выборку, изменение или удаление данных, уже существующих в базе, или на добавление в нее новых данных. Другими словами, СУБД должна включать в себя компонент процессора ЯМД или компилятора ЯМД, обеспечивающего поддержку языка манипулирования данными(ЯМД).

    В целом, запросы ЯМД подразделяются на планируемые и непланируемые.

    • а) Планируемый запрос -- это запрос, необходимость выполнения которого была предусмотрена заранее. Администратор базы данных, возможно, должен будет разработать физический проект базы данных таким образом, чтобы гарантировать достаточное быстродействие выполнения подобных запросов.
    • б) Непланируемый запрос -- это, наоборот, некоторый произвольный запрос на выборку или (что менее вероятно) на обновление, необходимость выполнения которого не была предусмотрена заранее и возникла по какой-то особой причине.

    ¦ Оптимизация и выполнение

    Запросы ЯМД, планируемые или непланируемые, должны быть обработаны таким компонентом, как оптимизатор, назначение которого состоит в поиске достаточно эффективного способа выполнения каждого из запросов. Затем оптимизированные запросы выполняются под управлением диспетчера этапа прогона (run-time manager).

    ¦ Защита и поддержка целостности данных

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

    ¦ Восстановление данных и поддержка параллельности

    СУБД или другой связанный с ней программный компонент, обычно называемый диспетчером транзакций или диспетчером выполнения транзакций, должен обеспечивать необходимый контроль над восстановлением данных и управление параллельной обработкой.

    ¦ Словарь данных

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

    AN INTRODUCTION TO

    Database Systems

    SEVENTH EDITION

    ВВЕДЕНИЕ В

    системы

    баз данных

    СЕДЬМОЕ ИЗДАНИЕ


    Москва Санкт-Петербург Киев 2001


    К. Дж. Дейт

    ББК 32.973.26-018.2.75 Д27

    Издательский дом "Вильяме"

    Перевод с английского канд.физ.-мат.наук Ю Г Гордиенко, В В Репецкого, А.В. Слепцова Под редакцией А.В. Слепцова

    По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу: info @ williamspublishing . com , http :// www . williamspublishing com

    Дейт, К., Дж.

    Д27 Введение в системы баз данных, 7-е издание.: Пер. с англ. - М. : Издательский дом "Вильяме", 2001. - 1072 с. : ил. - Парал. тит. англ.

    ISBN 5-8459-0138-3 (рус.)

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

    ББК 32.973.26-018.2.75

    Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм

    Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства Addison - Wesley Publishing Company , Inc

    Authorized translation from the English language edition published by Addison-Wesley Publishing Company, Inc. Copyright © 2000

    All rights reserved No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher

    Russian language edition published by Williams Publishing House according to the Agreement with R&I Enterprises International, Copyright © 2001

    Isbn 5-8459-0138-3 (рус) isbn 0-201-38590-2 (англ)

    © Издательский дом " Вильяме ", 2001 © Addison-Wesley Longman, lnc, 2000

    Эта книга посвящается моей жене Линди и памяти моей матери Риме

    ЧАСТЬ I. ОСНОВНЫЕ ПОНЯТИЯ 31

    Глава 2. Архитектура системы баз данных 65

    ЧАСТЬ I!. РЕЛЯЦИОННАЯ МОДЕЛЬ 149

    Глава 6. Реляционная алгебра 192

    Глава 7. Реляционное исчисление 243

    Глава 8. Целостность данных 301

    Глава 9. Представления 350

    ЧАСТЬ III . ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ 397

    Глава 10. Функциональные зависимости 400

    Глава 11. Дальнейшая нормализация: формы 1НФ, 2НФ, ЗНФ и НФБК 422 Глава 12. Дальнейшая нормализация: более высокие нормальные формы 469

    Глава 13. Семантическое моделирование 505

    ЧАСТЬ IV. УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ 543

    Глава 14. Восстановление 544

    Глава 15. Параллельность 566

    ЧАСТЬ V. ДОПОЛНИТЕЛЬНЫЕ АСПЕКТЫ 601

    Глава 16. Защита данных 602

    Глава 17. Оптимизация 639

    Глава 18. Отсутствующая информация 693

    Глава 19. Наследование типов 725

    Глава 20. Распределенные базы данных 767

    Глава 21. Поддержка принятия решений 813

    Глава 22. Хронологические базы данных 853

    Глава 23. Логические системы управления базами данных 899

    ЧАСТЬ VI. ОБЪЕКТНЫЕ И ОБЪЕКТНО-РЕЛЯЦИОННЫЕ

    БАЗЫ ДАННЫХ 943

    Глава 24. Объектные базы данных 944

    Глава 25. Объектно-реляционные базы данных 999

    ПРИЛОЖЕНИЯ 1027

    Приложение А. Выражения языка SQL 1028

    Приложение Б. Обзор языка SQL3 1041

    Приложение В. Сокращения и специальные символы 1058

    Предисловие к седьмому изданию 24

    ЧАСТЬ I

    Основные понятия 31

    Глава 1. Базы данных и управление ими 32

      Вводный пример 32

      Что такое система баз данных 35

    Аппаратное обеспечение 37

    Программное обеспечение 38

    Пользователи 39

    1.3. Что такое база данных 40

    Перманентные данные 40

    Сущности и связи 41

    Свойства 43

    Данные и модели данных 44

    1.4. Назначение баз данных 45

    Администрирование данных и администрирование базы данных 46

    Преимущества централизованного подхода к управлению данными 47

      Независимость данных 50

      Реляционные и другие системы 56

      Резюме 59 Упражнения 59 Список литературы 61 Ответы к некоторым упражнениям 62

    Глава 2. Архитектура системы баз данных 65

      Введение 65

      Три уровня архитектуры 65

      Внешний уровень 68

      Концептуальный уровень 72

      Внутренний уровень 73

      Отображения 74

      Администратор базы данных 74

      Система управления базой данных 77

      Система управления передачей данных 81

      Архитектура "клиент/сервер" 81

      Утилиты 83

      Распределенная обработка 84

    Упражнения 88

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

    Глава 3. Введение в реляционные базы данных 92

      Введение 92

      Реляционная модель 92

      Отношения и переменные-отношения 97

      Смысл отношений 99

      Оптимизация 101

      Каталог 104

      Базовые переменные-отношения и представления 105

      Транзакции 109

      База данных поставщиков и деталей 110

    3.10. Резюме 113 Упражнения 115 Список литературы 116 Ответы к некоторым упражнениям 117

    Глава 4. Введение в язык SQL 119

      Введение 119

      Обзор языка SQL 120

      Каталог 124

      Представления 125

      Транзакции 126

      Внедрение SQL-операторов 126

    Операции, не использующие курсоры 130

    Операции, использующие курсоры 131

    Динамический SQL 134

      Несовершенство языка SQL 136

      Резюме 136 Упражнения 137 Список литературы 140 Ответы к некоторым упражнениям 145

    ЧАСТЬ II

    Реляционная модель 149

    Глава 5. Домены, отношения и базовые переменные-отношения 151

      Введение 151

      Домены 152

    Каждое значение имеет тип 154

    Определение типа 155

    Допустимые представления 156

    Определение операторов 159

    Преобразование типов 161

    Заключительные замечания 162

    5.3. Значения отношений 163

    Свойства отношений 166

    Атрибуты, значениями которых являются отношения 168

    Отношения и их интерпретация 169

    5.4. Переменные-отношения 169

    Определение базовых переменных-отношений 169

    Обновление переменных-отношений 171

    5.5. Средства SQL 174

    Домены 174

    Базовые таблицы 177

    5.6. Резюме 178 Упражнения 180 Список литературы 181 Ответы к некоторым упражнениям 185

  • Коннолли Т., Бегг К., Страчан А. Базы данных: Проектирование, Реализация и сопровождение. Теория и практика (Документ)
  • Гарсиа-Молина Гектор, Ульман Дж., Уидом Дж. Системы баз данных. Полный курс (Документ)
  • Токмаков Г.П. Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML (Документ)

    • n1.doc

    Дейт К. Введение в системы баз данных. К.; М.; Спб; Издат. Дом «Вильямс». 2000.
    Реляционная модель (стр. 81-100)
    Часть II

    Реляционная модель

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

    Как уже отмечалось в главе 3, в реляционной модели рассматриваются три аспекта данных - структура данных (объекты данных), целостность данных и обработка данных (операторы). В этой части книги рассматривается каждый из трех аспектов: в главе 4 обсуждаются объекты, в главе 5 - целостность, в главах 6 и 7 - операторы. (Мы посвятили последней теме две главы, поскольку операционную часть модели можно реализовать двумя различными, но эквивалентными способами, известными соответственно как реляционная алгебра и реляционное исчисление) Назначение главы 8 будет описано ниже.

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

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

    Глава 4

    Реляционные объекты данных: домены и отношений


      1. 4.1. Вводный пример
    Как отмечалось в главе 3 реляционная модель делится на три части, в которых рассматриваются соответственно объекты, целостность и операторы. Во всех трех частях есть свои специальные термины. Наиболее важные термины, используемые в части "объектов" (предмет настоящей главы), показаны на рис. 4.1. В качестве иллюстрации взята таблица S из базы данных поставщиков и деталей. Речь идет о терминах отношение, кортеж, кардинальное число, атрибут, степень, домен и первичный ключ (вы уже должны быть знакомы по крайней мере с терминами отношение и первичный ключ). Сейчас мы дадим неформальное объяснение каждого термина, а в последующих разделах представим формальные определения.

    Итак, вкратце:


    • ■ Отношение соответствует тому, что мы до сих пор называли таблицей.

    • ■ Кортеж соответствует строке этой таблицы, а атрибут - столбцу. Количество кортежей называется кардинальным числом, а количество атрибутов - степенью.

    • ■ Первичный ключ - это уникальный идентификатор для таблицы, т.е. столбец или такая комбинация столбцов, что в любой момент времени не существует двух строк, содержащих одинаковое значение в этом столбце или комбинации столбцов.

    • ■ И наконец, домен - это общая совокупность значений, из которой берутся настоящие значения для определенных атрибутов определенного отношения. Например, домен, обозначенный S# на рис. 4.1 - это множество всех допустимых значений номера поставщика, а множество значений S# в отношении S в любой момент времени является подмножеством этого множества. Точно так же множество значений S# в отношении SP в любой момент времени является подмножеством этого множества.
    На рис. 4.2 представлен обзор этих терминов. Этот рисунок требует некоторых пояснений.

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

    1. 2. Понятие домена является иллюстрацией одного важного момента, о котором шла речь в главе 3, - не все реляционные системы поддерживают полностью все аспекты реляционной модели. На самом деле в главе 3 мы дали общее описание реляционных систем, не упоминая доменов вообще.

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

    Теперь перейдем к формальному изложению.


      1. 4.2. Домены
    В качестве отправной точки возьмем наименьшую семантическую единицу данных, которая предполагается отдельным значением данных (таким как отдельный номер поставщика, отдельный вес детали или отдельное количество деталей в поставке). Мы будем называть такие значения скалярами (хотя этот термин редко используется в реляционной литературе). Скалярные значения представляют собой "наименьшую семантическую единицу данных" в том смысле, что они атомарные: у них нет внутренней структуры (т.е. они неразложимы) в реляционной модели, а значит, и при рассмотрении в реляционной СУБД. Обратите особое внимание на то, что не иметь внутренней структуры при рассмотрении в реляционной модели вовсе не значит не иметь внутренней структуры вообще. Например, название города, конечно же, имеет внутреннюю структуру (оно состоит из последовательности букв); однако, разложив название по буквам, мы потеряем значение. Значение станет понятным, лишь в том случае, если буквы сложены вместе и в правильной последовательности.

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

    Теперь можно определить домен как именованное множество скалярных значений одного типа. Например, домен номеров поставщиков - это множество всех возможных номеров поставщиков; домен количества деталей для поставок - это множество всех целых чисел, больших нуля и меньших, скажем, 10 000. Итак, домены являются общими совокупностями значений, из которых берутся реальные значения атрибутов. Точнее, каждый атрибут должен быть определен на единственном домене (или на основе одного домена); это значит, что значения атрибута должны браться из этого домена. Например, атрибут номера детали для отношения Р и атрибут номера детали для отношения SP определены на домене номера детали (потому что эти два атрибута, бесспорно, представляют номера деталей). Другими словами, в любой момент времени каждое значение Р# в отношении Р должно быть значением из домена номера детали, то же верно для значения Р# в отношении SP. Иными словами, в любой момент времени набор значений Р# в отношении Р является некоторым подмножеством множества значений домена номера детали, и то же верно для значения Р# в отношении SP.

    Между прочим, обратите внимание, что обычно в любой момент времени в домене будут значения, не являющиеся значением ни одного из атрибутов, соответствующих этому домену. Например, если значение Р8 - допустимое значение детали, то оно входит в домен номера детали, даже если в нашем отношении Р из примера базы данных поставщиков и деталей нет детали Р8, т.е. в данный момент не существует такой детали.

    Сравнения, ограниченные доменом

    В чем состоит значение доменов? Один из наиболее важных ответов на этот вопрос следующий: домены ограничивают сравнения. Поясним сказанное. Рассмотрим два запроса SQL к базе данных поставщиков и деталей (заметьте, что оба запроса используют соединение):

    Один из этих запросов, а именно левый, возможно, имеет смысл, тогда как правый, скорее всего, - нет. Откуда это известно? С формальной точки зрения ответ заключается в том, что запрос слева использует сравнение между атрибутами Р.Р# и SP.P#, которые (как уже упоминалось) определены на одном и том же домене, в то время как запрос справа использует сравнение между атрибутами P.WEIGHT и SP.QTY, которые, вероятно, определены на разных доменах. (Мы здесь говорим "вероятно", поскольку, хотя вес и количество являются числами, это числа разного "сорта". Не имеет смысла сравнивать вес и количество. Поэтому домены веса и количества должны быть различными.)

    Следовательно, в соответствии с предыдущими рассуждениями, если значения двух атрибутов взяты из одного и того же домена, тогда сравнения, а отсюда и соединения, объединения и многие другие операции, использующие такие два атрибута, тоже, вероятно, будут иметь смысл, так как в них сравнивается подобный атрибут с подобным. И наоборот, если значения двух атрибутов взяты из различных доменов, тогда сравнения и другие операции, наверное, не будут иметь смысла. Поэтому преимущество системы поддержки доменов заключается в том, что такая система способна предотвратить грубые ошибки. Обратите внимание, что здесь легко допустить механическую ошибку, например набрав S# вместо Р#. Если пользователь попробует выполнить операцию, использующую сравнение значений разных доменов, система прервет свою работу и сообщит пользователю о возможной ошибке. (Мы говорим "возможной", поскольку могут быть обстоятельства, при которых такое сравнение не является ошибкой. Но об этом в следующих частях книги.)

    Между прочим, следует отметить, что хотя все примеры, которые мы приводили, были выражены в терминах языка SQL, этот язык на самом деле не поддерживает доменов в том смысле, который мы им придаем. Оба указанных выше запроса допустимы в SQL. Однако второй, конечно же, даст бессмысленный ответ.

    Определение данных

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

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

    CREATE DOMAIN domain data-type ;

    Здесь domain- это имя нового домена, a data - type соответствует типу данных, например CHAR(n ) или NUMERIC(n ). Замечание. Далее в книге мы обсудим некоторые дополнительные компоненты оператора CREATE DOMAIN, не показанные выше.

    На рис. 4.3 (такой же рисунок уже приводился в главе 3) показано, как с помощью этого языка можно определить базу данных поставщиков и деталей. Обратите внимание, что в этом примере наряду с операторами CREATE DOMAIN используются операторы CREATE BASE RELATION. Полное описание оператора здесь мы лишь отметим, что каждое определение атрибута в операторе CREATE BASE RELATION включает ссылку на соответствующий домен.

    При создании нового домена с помощью оператора CREATE DOMAIN СУБД создает запись в каталоге с описанием этого нового домена. (Чтобы вспомнить, что такое каталог, обратитесь еще раз к главе 3.) Точно так же при создании нового отношения с помощью оператора CREATE BASE RELATION СУБД создает запись в каталоге с описанием этого нового отношения.

    Замечание о названиях. Для определенности будем предполагать следующие ограничения на названия:


    • ■ Домены имеют уникальные имена в базе данных.

    • ■ Именованные отношения имеют уникальные имена в базе данных.

    • ■ Атрибуты имеют уникальные имена в содержащем их отношении (даже если содержащее их отношение не именовано!).
    Вообще говоря, атрибут может иметь как имя, совпадающее с именем соответствующего домена, так и отличное от него имя. Очевидно, чтобы избежать двусмысленности, следует использовать разные имена (в частности, если два атрибута в одном отношении основаны на одном домене). Однако в общем желательно называть атрибуты таким же именем, что и лежащий в основе домен, или, по крайней мере, называть так, чтобы, например, в имени атрибута содержалась ключевая часть имени домена. Мы следуем этому указанию и в примере на рис. 4.3.

    Можно дополнительно придерживаться другого общего соглашения и полностью опускать ссылку к основному домену из определения любого атрибута, который имеет то же самое имя, что и домен. Например, оператор CREATE BASE RELATION для базового отношения S может быть упрощен:

    Удаление доменов. Мы уже знаем, как создать новый домен. Должна также быть возможность удалить существующий домен, если мы больше в нем не нуждаемся:

    DESTROY DOMAIN domain ;

    Здесь domain - это имя удаляемого домена. С помощью этой операции удаляется элемент каталога, описывающий домен, поэтому такой домен становится неизвестным для системы. (До особого указания будем подразумевать, что операция DESTROY DOMAIN просто не будет выполняться, если какое-нибудь базовое отношение в этот момент еще включает атрибут, который определен на указанном домене.)

    Запросы, основанные на доменах. Вот другой пример практического значения доменов. Рассмотрим запрос, который формулируется так:

    "Какие отношения в базе данных содержат какую-либо информацию, имеющую отношение к поставщикам?"

    Этот вопрос может быть сформулирован более точно:

    "Какие отношения в базе данных включают атрибут, который определен на домене поставщика?"

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

    Домены и типы данных

    Включение этого раздела вызвано тем, что многие читатели уже вполне готовы понять следующее: домен - это на самом деле ни больше ни меньше, чем тип данных (как это понимается в современных языках программирования). Например, в языке программирования Pascal допустимы следующие выражения:

    Здесь мы имеем определенный пользователем тип, названный "Day" (имеющий в точности семь допустимых значений), и переменную, названную "Today", принадлежащую этому типу данных (а значит, ограниченную этими семью значениями). Очевидно, что эта ситуация полностью аналогична ситуации в реляционной базе данных, когда мы имеем домен, названный "Day", и атрибут, названный "Today", Более того, существуют языки программирования, например SIMULA 67, MODULA-2 или Ada (однако Pascal в их число не входит), которые поддерживают некоторые или даже все функции, обычно приписываемые доменам в реляционной модели .

    Исходя из того, что домен в своей основе является просто типом данных, было бы неверно утверждать, что СУБД вовсе не поддерживают доменов. В действительности системы поддерживают домены в очень примитивном смысле, так же как они предоставляют определенные встроенные (т.е. определенные системой) примитивные типы данных, такие как тип целых чисел или тип чисел с плавающей точкой. Но, если говорить о поддержке доменов в контексте реляционных систем, мы имеем в виду нечто большее, чем такая примитивная поддержка, а именно то, что система должна обеспечивать возможность пользователю создавать свои, более сложные типы данных, такие как "номера поставщиков", "номера деталей", "названия городов", "цвета" и т.д., а также обеспечивать все возможности для работы с этими типами.

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


      1. 4.3. Отношения
    А теперь попытаемся точно выяснить, что же такое "отношение". Вначале следует отметить, что исторически вокруг этого относительно простого понятия сложилась некоторая двусмысленность (это касается и предыдущих изданий книги). Причина кроется в отсутствии четкого разграничения между переменными отношений и значениями отношений. Переменная отношения - это обычная переменная, такая же как и в языках программирования, т.е. именованный объект, значение которого может изменяться со временем. А значение этой переменной в любой момент времени и будет значением отношения. Например, с помощью выражения

    Создается переменная отношения с именем s, значение которой в любой момент времени будет определенным значением отношения. 1

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

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

    Значения отношений

    Вот определение термина "отношение" (специфически обозначающего значение отношения):


    • ■ Отношение R , определенное на множестве доменов D 1, D 2,..., Dn (не обязательно различных), содержит две части: заголовок и тело. (Если представить отношение в терминах таблиц, заголовок - это строка заголовков столбцов, а тело - это множество строк данных.)

    1. 1. Заголовок содержит фиксированное множество атрибутов или, точнее, пар:
    {A 1: D 1>, A 2: D 2>, ..., A 1: Dn > },

    Причем каждый атрибут Aj соответствует одному и только одному из лежащих в основе доменов Dj (j = 1,2,..., n ). Все имена атрибутов А1, А2,..., An разные.


    1. 2. Тело содержит множество кортежей . Каждый кортеж, в свою очередь, содержит множество пар:
    { , vi2>, ..., А n: vin> }

    (i = 1,2, ..., т, где т - количество кортежей в этом множестве). В каждом таком кортеже есть одна такая пара, т.е. Aj : vij >, для каждого атрибута Aj в заголовке. Для любой такой пары Aj : vij > vij является значением из уникального домена Dj , который связан с атрибутом Aj .

    Значения т и п называются соответственно кардинальным числом и степенью отношения R .

    В качестве примера давайте рассмотрим таблицу S из рис. 4.1 (мы умышленно сейчас не называем ее отношением), чтобы проверить, как она соответствует этому определению.


    • ■ Во-первых, в этой таблице есть четыре основных домена, а именно: домен номеров поставщиков (S#), домен имен (NAME), домен значений статуса (STATUS) и домен наименований городов (CITY). (Изображая отношение как таблицу на листе бумаги, мы обычно не заботимся о том, чтобы показать лежащие в основе домены, но должны понимать, что, по крайней мере концептуально, они всегда есть.)

    • ■ Далее, в таблице непременно есть две части: строка заголовков столбцов, а также множество строк данных. Рассмотрим вначале строку заголовков столбцов:
    (S#, SNAME, STATUS, CITY)

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

    Замечание. На практике заголовок отношения обычно рассматривают просто как набор имен атрибутов (т.е. имена доменов часто опускаются), за исключением случаев, когда очень важна точность. Хотя, возможно, эта практика несколько небрежна, но она удобна, и мы часто будем ею пользоваться.


    • ■ Что касается остальной таблицы, то это; конечно, набор строк. Давайте сконцентрируем внимание на какой-нибудь одной строке, скажем, на строке

    Эта строка в действительности представляет набор упорядоченных пар:

    Первый компонент каждой пары - это имя атрибута, второй компонент - соответствующее значение атрибута. Часто в неформальном описании опускают имена атрибутов, так как известно, что каждое отдельное значение в таблице в действительности является значением атрибута, имя которого находится сверху соответствующего столбца; кроме того, мы знаем, что значение принадлежит лежащему в основе этого атрибута домену. Например, значение "S1" - это значение атрибута S#, и оно взято из соответствующего лежащего в основе домена, а именно домена номера поставщика (который также называется S#). Таким образом, можно условиться, что каждая строка представляет кортеж в соответствии с определением.

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

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

    (Ведь тот же набор значений отношения можно представить и не в виде таблицы, а например, в виде перечисляющегося списка. Например, в отделе А работают Иванов, Петров и Сергеев, а в отделе Б - Григорьев и Николаев. Такое перечисление не является таблицей (во всяком случае в данном контексте), хотя эти значения и составляют некое отношение служащих и отделов. - Прим. ред.)

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

    Переменные отношений

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

    CREATE BASE RELATION S ... ;

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

    Однако "изменяющийся со временем" - не очень удачный термин. В конце концов, если в некотором языке программирования используется приведенное выше объявление

    DECLARE QTY INTEGER ...;

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

    Теперь пусть R - переменная отношения; переменная R будет иметь разные значения в разное время. Однако все возможные значения переменной R будут иметь одинаковые заголовки. Например, все возможные значения базового отношения S будут иметь заголовок {S#,SNAME,STATUS,CITY}. 2

    И еще о терминологии

    Как мы уже объясняли, количество атрибутов в данном отношении называется степенью (иногда называют арностью ) отношения. Отношение первой степени называется унарным, отношение степени 2 -- бинарным, отношение степени 3 - тернарным... и отношение степени п - п-арным. (В общем случае в реляционной модели рассматриваются n -арные отношения, где п - произвольное неотрицательное целое число.) В базе данных поставщиков и деталей отношения S, P и SP имеют степень 4, 5 и 3, соответственно.

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

    "Не различные домены"

    Вернемся вновь к определению отношения; обратите внимание, что лежащие в основе отношения домены не обязательно все различны. Это значит, что несколько атрибутов в отношении могут иметь основой один домен. Пример такого отношения показан на рис. 4.4. (Это отношение названо PART_STRUCTURE.)

    Если один и тот же домен используется более одного раза в одном и том же отношении, то, как указывалось ранее, нельзя дать всем атрибутам имена, совпадающие с именами лежащих в их основе доменов. На рис. 4.4 показан рекомендуемый в такой ситуации подход: называть атрибуты по-разному, так, чтобы в качестве префикса у этих имен было "ролевое" имя атрибута, а в качестве суффикса - имя домена. Действительно, если условиться всегда следовать этому правилу, а также всегда использовать одинаковые символы разделения (например, такие как символ подчеркивания), чтобы отделять ролевое имя (если оно есть) от имени домена, то нам при определении атрибута никогда не понадобится в явном виде спецификация "DOMAIN (domain )" (об этом подробнее в следующем разделе).

    Определение данных

    Вот синтаксис оператора create base relation:

    При выполнении этого оператора создается новое базовое отношение с именем base - relation , а также указанные атрибуты, потенциальные и внешние ключи. Отношение создается пустым (т.е. не содержит кортежей). Несколько примеров использования этого оператора вы найдете на рис. 4.3. Ниже приводятся некоторые пояснения к оператору.


    1. 1. Термины list (список) и commalist (список, разделенный запятыми) удобно использовать при описании операторов (они будут использоваться здесь и далее в книге). В общем они значат следующее:

    • Если xyz - синтаксическая единица, то xyz - list -- xyz , количество которых больше либо равно нулю, причем каждые две единицы xyz между собой разделены по крайней мере одним пробелом.

    • Если xyz - синтаксическая единица, то xyz - commalist - это синтаксическая единица, которая xyz , количество которых больше либо равно нулю, причем каждые две единицы xyz между собой разделены запятой (и возможно, одним или несколькими пробелами).
    Так, например, список определения атрибутов attribute - defenition - commalist состоит из последовательности единиц attribute - defenition (т.е. определений атрибутов), каждая из которых, за исключением последней, отделяется от следующей запятой, а список определения потенциальных ключей candidate -k ey - definition - list состоит из последовательности единиц candidate - key - definition (т.е. определений потенциальных ключей), каждая из которых, за исключением последней, отделяется от следующей по крайней мере одним пробелом. То же самое можно сказать о списке определения внешних ключей foreign - key - definition - list .

    1. 2. Определение атрибута имеет следующую форму:
    attribute DOMAIN (domain )

    Если опустить спецификацию "DOMAIN (domain)", то считается, что атрибут основан на домене с тем же именем.


    1. 3. Определение потенциальных ключей подробно объясняется в следующей главе. А пока будем просто предполагать, что в каждом операторе create base relation есть только одно определение в следующей форме:
    PRIMARY KEY (attribute-commalist)

    1. 4. Определения внешних ключей также объясняются в следующей главе.
    Удаление базовых отношений. Вот синтаксис оператора удаления существующего базового отношения:

    DESTROY BASE RELATION base-relation ;

    Эта операция предназначена для удаления всех кортежей указанного базового отношения о последующим удалением всех записей в каталоге об этом отношении. После этого отношение больше не "известно системе. (Если нет указания, то мы предполагаем, что операция DESTROY BASE RELATION просто не будет выполняться, если существует определение представления, которое ссылается на удаляемое базовое отношение. Дальнейшее обсуждение этого вопроса приводится в следующих частях книги,)

    Свойства отношений

    У отношений есть определенные свойства, все они являются непосредственными свойствами данного ранее определения отношения, и все они имеют очень важное значение. Мы сначала кратко укажем эти свойства, а затем подробно их обсудим. Речь идет о перечисленных ниже четырех свойствах. В любом отношении


    • ■ нет одинаковых кортежей;

    • ■ кортежи не упорядочены сверху вниз;

    • ■ атрибуты не упорядочены слева направо;

    • ■ все значения атрибутов атомарные.

    1. 1. Нет одинаковых кортежей.
    Это свойство следует из того факта, что тело отношения - это математическое множество (кортежей), а множества в математике по определению не содержат одинаковых элементов.

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

    Важным следствием того факта, что не существует одинаковых строк, является то, что всегда существует первичный ключ 3 . Так как кортежи уникальны, то по крайней мере комбинация всех атрибутов будет обладать свойством уникальности, а значит, при необходимости может служить первичным ключом. На практике, конечно, обычно нет необходимости использовать все атрибуты - подходит комбинация из нескольких атрибутов. В главе 5 будет дано определение первичного ключа, как не включающего в себя атрибуты, излишние с точки зрения уникальности; поэтому, например, комбинация {S#,CITY} хотя и "уникальна", но она не является первичным ключом, так как мы можем убрать атрибут CITY, не нарушив уникальности. (Однако заметьте, что первичные ключи могут быть составными. Примером тому может служить отношение SP.)


    1. 2. Кортежи не упорядочены (сверху вниз).
    Это свойство также следует из того, что тело отношения - это математическое множество, а простые множества в математике не упорядочены. Например, на рис. 4.1 кортежи отношения S могли быть расположены в противоположном порядке - это было бы тем же самым отношением. Поэтому в отношении нет понятий "пятого кортежа", “97-го кортежа" или "первого кортежа"; т.е. нет понятия позиционной адресации и понятия "последовательности". 4 В статье , которая уже упоминалась в связи со свойством "нет одинаковых кортежей", показано, почему свойство "кортежи не упорядочены" также имеет важное значение (в действительности эти свойства взаимосвязаны).

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


    1. 3. Атрибуты не упорядочены (слева направо).
    Это свойство следует из того факта, что заголовок отношения также определен как множество (атрибутов). Например, на рис. 4.1 атрибуты отношения S могли быть представлены, скажем, в таком порядке: SNAME, CITY, STATUS, S# - это было бы то же самое отношение, по крайней мере с точки зрения реляционной модели. Поэтому не существует понятий "первого атрибута" или "последнего атрибута" (и т.д.), не существует "следующего атрибута" (опять же нет понятия "последовательности"); иначе говоря, атрибут всегда определяется по имени, а не по расположению. Это позволяет избежать некоторых ошибок и неясности при написании программ. Например, не существует (или не должно существовать) возможности сбоя системы из-за "залезания" одного атрибута на другой. Эта ситуация отличается от ситуации во многих системах программирования, где можно использовать физическую смежность логически дискретных элементов (умышленно или случайно) различными методами, потенциально способными повредить систему.

    Заметим, что вопрос порядка атрибутов- это еще одна область, где конкретное представление отношения в виде таблицы предполагает неверные факты: столбцы таблицы упорядочены слева направо, а атрибуты отношения - нет.


    1. 4. Все значения атрибутов атомарные.
    Последнее свойство является следствием того, что все лежащие в основе домены содержат только атомарные значения. Это свойство можно выразить и иначе (довольно неформально): в каждой позиции пересечения столбца и строки в таблице расположено в точности одно значение, а не набор значений. Можно сказать еще и так: отношения не содержат групп повторения. Отношение, удовлетворяющее этому условию, называется нормализованным, или представленным в первой нормальной форме (другие нормальные формы - вторая, третья - обсуждаются в следующих частях книги).

    Сказанное означает, что с точки зрения реляционной модели все отношения нормализованы. Это значит, что термин "отношение" всегда означает "нормализованное отношение" в контексте реляционной модели. Но дело в том, что математическое отношение вовсе не обязано быть нормализованным. Рассмотрим отношение BEFORE, изображенное на рис. 4.5. С математической точки зрения BEFORE является отношением степени два, в одном из доменов этого отношения значениями являются отношения.

    Следовательно, элементы этого домена сами являются отношениями, а не простыми скалярами. В этом примере атрибут PQ определен на основе домена со значениями-отношениями, элементами которого являются бинарные отношения; эти бинарные отношения определены, в свою очередь, на основе двух доменов со скалярными значениями, а именно доменов Р# и QTY. Реляционная модель не допускает доменов со значениями-отношениями (это еще будет обсуждаться далее в этой книге).

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

    Причина, по которой требуется нормализация всех таблиц, состоит в следующем. С математической точки зрения нормализованное отношение имеет более простую структуру. Вследствие этого требуется меньше операторов для работы с нормализованными отношениями и они проще. Например, рассмотрим две задачи.


    1. 1. Записать новую информацию о поставке для поставщика S5 деталей Р5 в количестве 500.

    2. 2. Записать новую информацию о поставке для поставщика S4 деталей Р5 в количестве 500.
    Для отношения AFTER нет существенной разницы в выполнении этих двух операций, каждое из них требует вставки одного кортежа в отношение. А для отношения BEFORE первая задача требует такой же вставки кортежа в отношение, но вторая задача требует существенно отличную операцию, а именно: вставку новой записи в набор записей (т.е. группу повторения) внутри существующего кортежа. Поэтому для поддержки ненормализованных операций нужны два совершенно разных оператора "INSERT". По аналогичным причинам также понадобятся два различных оператора "UPDATE", два различных оператора "DELETE" и т.д. Обратите внимание, что эти замечания касаются не только операторов обработки данных, но и всех операторов системы; например, нужны дополнительные операторы обеспечения безопасности данных, нужны дополнительные операторы обеспечения целостности данных и т.п. (И вообще, можно считать аксиомой то, что если у нас есть п путей представления данных, то нам потребуется п наборов операций.) Итак, ответ из одного слова на вопрос "Почему мы настаиваем на нормализации?" - это простота: простота объектов, с которыми мы работаем, что приводит к упрощению всей системы.

      1. 4.4. Виды отношений
    В этом разделе мы определим некоторые из видов отношений, встречающихся в реляционных системах (однако обратите внимание, что не все системы поддерживают каждый из этих видов).

    1. 1. Прежде всего, именованное отношение - это переменная отношения, определенная в СУБД посредством операторов CREATE BASE RELATION, CREATE VIEW и CREATE SNAPSHOT (в используемом нами синтаксисе). Об операторе CREATE VIEW рассказывалось в главе 3, а об операторе CREATE SNAPSHOT речь пойдет далее в этой главе.

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

    3. 3. Производным отношением называется отношение, определенное (посредством реляционного выражения) через другие именованные отношения и, в конечном счете, через базовые отношения.
    Предостережение. Помните, что некоторые авторы под "производным" подразумевают "выражаемое" (смотрите следующий пункт).

    1. 4. Выражаемым отношением называется отношение, которое можно получить из набора именованных отношений посредством некоторого реляционного выражения. Конечно, каждое именованное отношение является выражаемым отношением, но не наоборот. Базовые отношения, представления, снимки (об этом ниже), промежуточные и окончательные результаты отчетов - все это выражаемые отношения. Иначе говоря, множество всех выражаемых отношений - это в точности множество всех базовых отношений и всех производных отношений.

    2. 5. Представлением называется именованное производное отношение. (Представления, как и базовые отношения, являются переменными отношений.) Представления виртуальны - они представлены в системе исключительно через определение в терминах других именованных отношений.

    3. 6. Снимки (snapshot ) - это именованные производные отношения, такие же как представления (и подобно представлениям они являются переменными отношений). Однако в отличие от представлений снимки реальны, а не виртуальны, т.е. представлены не только с помощью определения в терминах других именованных отношений, но и также (по крайней мере концептуально) своими отдельными данными. Вот пример:

    Создание снимка похоже на выполнение запроса, за исключением того, что результат такого запроса сохраняется в базе данных под определенным именем (SC в нашем примере) как отношение, доступное только для чтения, и периодически (в нашем примере - каждый день) снимок "обновляется", т.е. его текущее значение сбрасывается, запрос выполняется снова и его результат становится новым значением снимка. Применение снимков будет обсуждаться в следующих частях книги.


    1. 7. Результатом запроса называется неименованное производное отношение, служащее результатом некоторого определенного запроса, База данных не обеспечивает постоянного существования для результатов запросов (чтобы сохранить результат запроса, его можно присвоить некоторому именованному отношению).

    2. 8. Промежуточным результатом называется неименованное производное отношение, являющееся результатом некоторого реляционного выражения, вложенного в другое, большее выражение. Например, рассмотрим такое выражение:

    Отношение, являющееся результатом выражения S JOIN SP будет промежуточным результатом; назовем его TEMP1. Тогда отношение, являющееся результатом выражения TEMP1 WHERE P# = "P2", также будет промежуточным результатом; назовем его TEMP2. А отношение, являющееся результатом выражения TEMP2 , будет окончательным результатом. База данных не обеспечивает постоянного существования для промежуточных результатов, как и для окончательных результатов (в действительности, как уже упоминалось в главе 3, они могут не существовать в виде полной материализованной таблицы как таковой).


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

      1. 4.5. Отношения и предикаты
    Хотя мы не останавливались на этом вопросе, читатель, наверное, интуитивно понимает, что каждое отношение имеет некоторую интерпретацию, причем пользователи должны знать ее для эффективного использования базы данных. Например, интерпретация отношения S может быть следующей:

    Поставщик с определенным номером (S #) имеет определенное имя (SNAME ) и определенное значение статуса (STATUS ) и располагается в определенном городе (CITY ); кроме того, нет двух поставщиков с одинаковыми номерами.

    Это утверждение не очень точное, но оно подходит для наших целей.

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

    S#= "SI" SNAME ="Smith1 STATUS = 20 CITY = "London"

    истиной. А при подстановке

    S#= "SI" SNAME = "Abbey" STATUS = 45 CITY = "Tucson"

    Получим высказывание, являющееся ложью (потому что поставщик с номером S1 имеет имя не Abbey, статус не 45 и располагается не в Туксоне). И в любой момент времени отношение содержит в точности те кортежи, при которых предикат является истиной.

    Из вышесказанного следует, что (например) кортеж, представленный в качестве кандидата для вставки в некоторое отношение, будет принят СУБД только в том случае, если он не противоречит соответствующему предикату (т.е. соответствующее высказывание не будет ложью). Вообще предикат данного отношения составляет критерий возможности обновления для этого отношения; т.е. критерий для решения, является ли некоторое обновление допустимым (или по крайней мере "правдоподобным") для данного отношения.

    Для того чтобы система могла определить допустимость обновления данного отношения, ей должен быть известен предикат этого отношения. Конечно, сейчас СУБД не может в точности знать предикат для данного отношения. Например, в случае отношения S СУБД не может знать точно, что предикат для кортежа (S1,Smith,20,London) будет истиной, а для кортежа (S1,Abbey,45,Tucson) - нет. 5 Однако СУБД считает кортеж приемлемым, если выполнены следующие условия:


    • Значение S# принадлежит домену номеров поставщиков.

    • Значение SNAME принадлежит домену имен.

    • Значение STATUS принадлежит домену значений статуса.

    • Значение CITY принадлежит домену названий городов.

    • Значение S# должно быть уникальным среди всех значений отношения.
    Иначе говоря, для базового отношения, такого как S, в СУБД используются определенные, объявленные для этого отношения, правила целостности, такие как правило о том, что значение S# уникально и принадлежит домену номеров поставщиков. Поэтому формально мы можем определить "значение" (известное СУБД) данного базового отношения как логическое умножение (логическая операция И) всех известных СУБД применяемых к этому отношению правил. И именно в этом смысле СУБД будет проверять допустимость обновления данного отношения.

    Мы будем еще несколько раз возвращаться к значению отношения в последующих главах.


      1. 4.6. Реляционные базы данных
    Исходя из обсуждений и объяснений этой главы, можно дать более формальное определение (более формальное, чем данное выше в этой главе) термина "реляционная база данных". Перефразировав определение, данное Коддом в , Получим следующее:

    Реляционная база данных - это база данных, воспринимаемая пользователем как набор нормализованных отношений (т.е. переменных отношений) разной степени.

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

    Различие между доменами и (именованными) отношениями также можно несколько уточнить. Мы называем именованные отношения переменными, так как их значения изменяются со временем. Как указывалось выше в этой главе, домены не являются переменными в этом смысле. Например, множество всех возможных номеров поставщиков, конечно, не изменяется со временем, или если изменяется, то изменение носит описательный характер, т.е. происходит на уровне типа, а не экземпляра. Это немного похоже на изменение основного типа данных для номера поставщиков с CHAR(5) на CHAR(7). Обратите внимание, что такое изменение, возможно, повлечет за собой реорганизацию базы данных.

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

    6 Если рассматривать отношения как таблицы, то мы могли бы сказать, что, например, переменная отношения S в разное время представляет разные таблицы. Однако заметьте, что в этих разных таблицах будут разные строки, а столбцы будут одинаковые.

    7 Для читателей, знакомых с языком SQL, отметим, что в SQL существует возможность добавлять новый столбец или удалять существующий столбец из базовой таблицы посредством оператора ALTER TABLE. Однако эту операцию лучше рассматривать не как изменение существующей таблицы, а как уничтожение существующей таблицы и создание новой с тем же именем и новым заголовком.

    8 Точнее, всегда существует по крайней мере один потенциальный ключ. Мы предполагаем, что один из потенциальных ключей выбран как первичный. Дальнейшее обсуждение этого вопроса приведено в главе 5.

    9 Понятие "последовательности" требуется для интерфейса между реляционной базой данных и базовым языком, таким как С или COBOL. Но это требование для базовых языков, а не для реляционной модели. В сущности, эти языки требуют, чтобы неупорядоченные множества были преобразованы в упорядоченные таким образом, чтобы могли выполняться операции типа "вызвать следующий кортеж". Заметьте также, что такие возможности составляют часть прикладного программного интерфейса-они не видны конечному пользователю.

    10 Здесь мы используем очевидное сокращение, согласно которому выражение (S1,Smith,20,London) соответствует кортежу { , }.

    Целостность реляционных данных (стр. 113-130)