«Boston • San Francisco • New York London • Toronto • Sydney • Tokyo • Singapore • Madrid Mexico City • Munich • Paris • Cape Town • Hong Kong • Montreal Введение в системы баз данных К. Дж. Дейт Москва • Санкт-Петербург ...»

Введение в системы

баз данных

An Introduction to

Database Systems

C.J.Date

Boston • San Francisco • New York

London • Toronto • Sydney • Tokyo • Singapore • Madrid

Mexico City • Munich • Paris • Cape Town • Hong Kong • Montreal

Введение в системы

баз данных

К. Дж. Дейт

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

2005

№.

ББК 32.973.26-018.2.75

Д27

УДК 681.3.07

Издательский дом "Вильяме" Зав. редакцией С.Н. Тригуб Перевод с английского и редакция К.А. Птицына По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу:

[email protected], http://www.williamspublishing.com 115419, Москва, а/я 783; 03150, Киев, а/я Дейт, К. Дж.

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

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

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

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

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

Authorized translation from the English language edition published by Addison-Wesley, Copyright © 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 © ISBN 5-8459-0788-8 (рус.) © Издательский дом "Вильяме", ISBN 0-321-19784-4 (англ.) © by Pearson Education, Inc., Оглавление Об авторе Предисловие к восьмому изданию

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

Глава 1. Базы данных и управление ими Глава 2. Архитектура системы баз данных Глава 3. Введение в реляционные базы данных Глава 4. Введение в язык SQL ЧАСТЬ II. РЕЛЯЦИОННАЯ МОДЕЛЬ Глава 5. Типы Глава 6. Отношения Глава 7. Реляционная алгебра Глава 8. Реляционное исчисление Глава 9. Целостность данных Глава 10. Представления

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

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

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

6 Оглавление Глава 24. Логические системы управления базами данных Глава 26. Объектно-реляционные базы данных Приложение В. Сокращения и специальные символы Приложение Г. Структуры хранения и методы доступа Приложение Д. Ответы к отдельным упражнениям Содержание Дополнительные материалы, доступные в оперативном режиме

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

Администрирование данных и администрирование базы данных Преимущества подхода, предусматривающего использование базы данных Глава 2. Архитектура системы баз данных 2.9 Система управления передачей данных Глава 3. Введение в реляционные базы данных 3.7 Базовые переменные отношения и представления Операции, в которых не используются курсоры Операции, в которых используются курсоры Динамический язык SQL и интерфейс SQL/CLI Возможные форматы представления, селекторы и операторы ТНЕ_ Сравнение типов кортежей и возможных представлений 10 Cодержание 7.2. Дополнительные сведения о реляционном свойстве замкнутости 7.5.1.Определить имена поставщиков, которые поставляют деталь Р2 7.5.2.Определить имена поставщиков, которые поставляют по меньшей.

7.5.3.Определить имена поставщиков, которые поставляют все детали 7.5.4.Определить номера поставщиков, поставляющих, по меньшей мере, 7.5.5.Определить все пары номеров поставщиков, таких что рассматриваемые поставщики находятся в одном городе 7.5.6.Определить имена поставщиков, которые не поставляют деталь Р2 Дополнительные сведения о свободных и связанных переменных 8.3.1 Определить номера поставщиков из Парижа со статусом, большим 8.3.2 Найти все пары номеров таких поставщиков, которые находятся 8.3.3 Получить полную информацию о поставщиках детали с номером Р 8.3.4 Определить имена поставщиков по крайней мере одной детали 8.3.5. Найти имена поставщиков по крайней мере одной детали, 8.3.6.Получить имена поставщиков всех типов деталей 8.3.7.Определить имена поставщиков, которые не поставляют деталь 8.3.8. Определить номера поставщиков, по крайней мере, тех деталей, которые поставляет поставщик сномером S2 (повторение примера 7.5.4) 8.3.9. Получить номера деталей, которые весят более 16 фунтов, поставляются поставщиком с номером S2 или соответствуют обоим условиям 8.4 Сравнительный анализ реляционного исчисления и реляционной алгебры 8.5.1. Определить номера и вес в граммах всех типов деталей, 8.5.2. Выбрать сведения обо всех поставщиках и обозначить каждого из них 8.5.3. Получить полные сведения о каждой поставке, включая общий 8.5.4. Для каждой детали получить номер детали и общий объем поставки 8.5.6. Для каждого поставщика получить номер поставщика и общий объем 8.5.7. Указать названия таких городов, в которых хранятся детали, что в них 8.6.1. Указать цвета деталей и названия городов для деталей, которые имеют 8.6.2. Для всех деталей указать номер детали и вес в граммах (упрощенная 8.6.3. Получить все комбинации данных о поставщиках и деталях, 8.6.4. Найти все пары названий городов, таких что поставщик, находящийся в первом городе, поставляет деталь, хранящуюся во втором городе 8.6.5. Получить все пары номеров поставщиков, таких что оба поставщика 12 Содержание 8.6.7. Определить максимальное и минимальное количество деталей 8.6.8. Для каждой поставляемой детали указать номер детали и общий объем поставки в штуках (модифицированная версия примера 8.5.4) 8.6.9. Определить номера всех деталей, поставляемых больше чем одним 8.6.10. Определить имена поставщиков детали с номером Р 8.6.11. Определить имена поставщиков по крайней мере одной детали 8.6.12. Определить номера поставщиков, имеющих статус меньше того, 8.6.14. Определить имена поставщиков, которые не поставляют деталь 8.6.15. Определить имена поставщиков, которые поставляют детали 8.6.16. Определить номера деталей, которые либо весят более 16 фунтов, либо поставляются поставщиком с номером S2, либо соответствуют и тому, 8.6.17. Определить номер детали и вес в граммах для каждой детали 8.7.1. Определить номера поставщиков из Парижа со статусом больше 8.7.2. Найти все такие пары номеров поставщиков, в которых два поставщика 8.7.3. Определить имена поставщиков по крайней мере одной детали 8.7.4 Определить имена поставщиков, которые поставляют хотя бы один тип деталей, поставляемых поставщиком с номером S2 (см. пример 8.3.5) 8.7.5. Определить имена поставщиков, которые поставляют детали 8.7.6. Определить имена поставщиков, которые не поставляют деталь 8.7.7. Определить номера поставщиков, которые поставляют, по меньшей мере, детали всех типов, поставляемых 8.7.8. Получить номера деталей, которые либо весят более16 фунтов, либо поставляются поставщиком с номером S2, либо соответствуют 8.8.1. Определить номера поставщиков, находящихся в Париже, которые 8.8.2. Определить номера всех поставляемых деталей, удалив ненужные 8.8.3. Получить номера и данные о статусе поставщиков, находящихся в Париже, вначале выполнив сортировку в порядке убывания 8.8.4. Получить номера и данные о статусе поставщиков, которые либо находятся в Париже, либо имеют статус > 20, либо соответствуют 8.8.5. Определить детали, вес которых находится в пределах от 8.8.6. Для всех деталей определить номер детали и вес детали в граммах 8.8.7. Определить номера поставщиков, которые поставляют деталь Р 8.8.8. Определить все пары номеров поставщиков и номеров деталей, такие что поставщик находится в том же городе, где хранится рассматриваемая деталь (модифицированная версия примера 8.6.3) 8.8.9. Определить все пары номеров поставщиков, таких что оба поставщика в каждой паре находятся водном городе (пример 8.6.5) 8.8.10 Определить общее количество поставляемых деталей Р2 8.8.11Для каждой поставляемой детали определить номер детали и общий 8.8.12. Определить номера всех деталей, поставляемых больше чем одним 8.8.13. Определить номера деталей, которые либо весят больше 16 фунтов, либо поставляются поставщиком S2, либо соответствуют и тому, 8.8.14. Вставить в таблицу Р данные о детали с номером Р7 (город Афины, 8.8.15. Удалить данные обо всех поставках, в которых количество 8.8.16. Изменить цвет детали Р2 на желтый, увеличить ее вес на пять 8.8.17. Для всех поставщиков, находящихся в Лондоне, изменить объем 9.4 Предикаты переменной отношения и предикаты базы данных 9.7 Сравнение понятий правильности и непротиворечивости 14 Содержание Ограничения переменной отношения и базы данных Принципы создания механизма обновления представлений 10.5 Снимки (небольшое отклонение от основной темы)

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

Глава 12. Дальнейшая нормализация: формы 1НФ, 2НФ, ЗНФ и НФБК 12.2. Декомпозиция без потерь и функциональные зависимости Дополнительные сведения о функциональных зависимостях 12.6 Примечание по поводу атрибутов, содержащих отношения в качестве Глава 13. Дальнейшая нормализация: нормальные формы более 13.2 Многозначные зависимости и четвертая нормальная форма 13.6. Ортогональное проектирование (небольшое отступление от темы) 16 Содержание 14.5. Проектирование базы данных с помощью метода ER-моделирования

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

15.7. Точки сохранения (отступление от основной темы) 16.4.Дальнейшее описание трех проблем организации параллельной работы 16.10. Критика подхода, основанного на использовании свойств ACID 18 Содержание Стадия 4. Генерация различных вариантов планов вычисления запроса 18.6. Стратегия организации работы по принципу "разделяй и властвуй" Сравнение операторов, обеспечивающих только чтение, и операторов 20.8. Анализ взаимодействия между типами и подтипами на примере 20 Содержание 20.9. Дополнительная информация об уточнении с помощью ограничений Промежуточное программное обеспечение для доступа к данным 22.2. Некоторые особенности технологии поддержки принятия решений 22.3. Проектирование базы данных для поддержки принятия решений Дополнительные сведения об обычных реляционных операциях 22 Содержание Определение "движущейся по временной шкале позиции текущего времени" 24.5. Доказательно-теоретическое представление баз данных Действительно ли можно рассматривать объектную СУБД Анализ источников возникновения первого серьезного заблуждения Несовместимость указателей и качественной модели наследования Анализ причин возникновения второго серьезного заблуждения 24 Содержание Дополнительные сведения о языках, производных от XML Применение сжатых таблиц в процессе реконструкции записей Приложение В. Сокращения и специальные символы Приложение Г. Структуры хранения и методы доступа 26 Содержание Шаг 0. Определить первоначальную структуру переменной отношения Шаг 1. Устранение атрибутов со значениями в виде отношения Об авторе К.Дж.Дейт (C.J.Date) — независимый публицист, лектор, ученый и консультант, специализирующийся на технологии реляционных баз данных. Он проживает в г. Хилдсбурге, штат Калифорния.

Начиная с 1967 года, Дейт несколько лет работал математиком-программистом и инструктором по программированию в компании Leo Computers Ltd. (Лондон, Великобритания). После этого он работал в лаборатории IBM (UK) Development Laboratories над интеграцией функций баз данных в язык PL/I. В 1974 году он перешел в калифорнийский центр IBM Systems Development Center, где отвечал за разработку языка баз данных, известного в настоящее время как Unified Database Language (UDL). Впоследствии Дейт принимал участие в техническом планировании и проектировании внешних интерфейсов для продуктов реляционных баз данных SQL/DS и DB2 корпорации IBM. В мае 1983 года он покинул компанию IBM.

Дейт работает с технологиями, связанными с базами данных, свыше 30 лет. Он одним из первых осознал основополагающее значение новаторской работы Э.Ф.Кодда (E.F.Codd) по реляционной модели. Дейт читал лекции по техническим вопросам (преимущественно по тематике баз данных, в частности по реляционным базам данных) во всей Северной Америке, а также в Европе, Австралии, Латинской Америке и на Дальнем Востоке. Он является автором или соавтором не только этой, но и других книг по базам данных:

Temporal Data and the Relational Model, 2003 (издательство Morgan Kaufmann); Foundation for Future Database Systems: The Third Manifesto (второе издание), 2000 (издательство Addison-Wesley), в которой даны развернутые предложения по развитию данной области;

Database: Л Primer, 1983, в которой базы данных рассматриваются с точки зрения неспециалиста; серии книг Relational Database Writings (1986, 1990, 1992, 1995 и 1998 годы), в которых фундаментально изложены различные вопросы реляционной технологии; а также серии книг, посвященных отдельным системам и языкам: A Guide to DB2 (четвертое издание), 1993; A Guide to SYBASE and SQL Server, 1992; A Guide to SQL/DS, 1988; A Guide to INGRES, 1987; и A Guide to the SQL Standard (четвертое издание), 1997. Книги Дейта переведены на многие языки, в том числе голландский, греческий, испанский, итальянский, китайский, корейский, немецкий, польский, португальский, русский, французский и японский. Кроме того, его книги изданы с использованием шрифта Брайля для слепых.

Дейт опубликовал больше 300 технических статей и научных работ и внес значительный вклад в теорию баз данных. В течение многих лет он ведет постоянную колонку в журнале Database Programming & Design. Кроме того, Дейт регулярно пополняет материалы Web-узла http://dbdebunk.com. Профессиональные семинары по технологии баз данных, проводимые им как в Северной Америке, так и в других регионах мира, считаются непревзойденными по качеству представленного материала и ясности изложения.

Дейт с отличием окончил Кембриджский университет в Великобритании (в 1962 году он защитил диплом бакалавра гуманитарных наук, а в 1966 году— магистра гуманитарных наук), а со временем получил почетную ученую степень доктора технических наук в де Монфортском университете в Великобритании (1994).

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

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

ДЛЯ КОГО ПРЕДНАЗНАЧЕНА ЭТА КНИГА

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

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

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

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

Часть II. Реляционная модель.

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

Часть IV. Управление транзакциями.

32 Предисловие к восьмому изданию Часть V. Дополнительные темы.

Часть VI. Объекты, отношения и язык XML Каждая часть в свою очередь разделена на несколько глав.

Часть I (четыре главы) — это обширное введение в теорию систем баз данных во обще и реляционных систем в частности. Здесь также излагаются основы стан дартного языка баз данных SQL.

Часть II (шесть глав) содержит подробное и весьма основательное описание реля ционной модели, которая является теоретической основой не только для собствен но реляционных систем, но фактически для всей сферы применения баз данных.

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

Часть IV (две главы) посвящена описанию средств управления транзакциями (т.е.

средств восстановления и обеспечения параллельной работы).

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

Наконец, в части VI (три главы) показано, какие следствия вытекают из стремле ния применить объектную технологию в системах баз данных. Глава 25 посвящена исключительно описанию объектных систем, в главе 26 рассматривается возможность сближения между объектной и реляционной технологиями и обсуждаются принципы построения объектно-реляционных систем, а в главе 27 приведено описание того, как связаны между собой объектная технология и базы данныхХML.

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

ДОПОЛНИТЕЛЬНЫЕ МАТЕРИАЛЫ, ДОСТУПНЫЕ В

ОПЕРАТИВНОМ РЕЖИМЕ

Представленные в этом разделе дополнительные материалы предназначены только для квалифицированных преподавателей. Для получения информации о том, как приобрести эти учебные материалы, обратитесь в местное торговое представительство издательства Addison-Wesley или отправьте по электронной почте письмо по адресу [email protected].

В руководстве для преподавателей Instructor's Manual даны указания о том, как ис пользовать эту книгу в ходе преподавания учебного курса, посвященного базам данных. В нем приведен ряд примечаний, советов и предложений по каждой час ти, главе и приложению, а также другой вспомогательный материал.

Ответы к упражнениям (включены в руководство Instructor's Manual).

Слайды в формате PowerPoint для демонстрации в ходе лекций.

Оригиналы следующих дополнений доступны всем читателям этой книги по адресу tp: //www.aw.com/cssupport (а перевод представлен в данной книге).

Приложение Г, где представлен материал по структурам хранения и методам доступа.

Ответы к отдельным упражнениям (приложение Д).

КАК ЧИТАТЬ ЭТУ КНИГУ

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

Бегло прочитать главы 1 и 2.

Очень внимательно изучить главы 3 и 4 (возможно, кроме разделов 4.6 и 4.7).

Бегло прочитать главу 5.

Внимательно прочитать главы 6, 7, 9 и 10, но пропустить главу 8 (возможно, кро ме раздела 8.6, посвященного языку SQL).

Бегло прочитать главу 11.

Внимательно прочитать главы 12 и 141, но пропустить главу 13.

Внимательно прочитать главы 15 и 16 (возможно, кроме раздела 15.6 с описанием двухфазной фиксации).

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

Примечание. Ссылки обозначаются в тексте двойным номером в квадратных скобках.

Например, ссылка [3.1] означает первый пункт в списке литературы к главе 3, а именно статью Э.Ф. Кодда, опубликованную в феврале 1982 года в журнале САСМ, том 25, № 2.

(Объяснение сокращений, которые используются в ссылках, например, "САСМ", можно найти в приложении В.) При желании можно приступить к изучению главы 14 еще при первом чтении, сразу после главы 4.

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

СРАВНЕНИЕ С ПРЕДЫДУЩИМИ ИЗДАНИЯМИ

Ниже перечислены главные отличия настоящего издания от непосредственно предшествующего ему издания.

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

Часть II. Главы 5-10, посвященные описанию реляционной модели, представляют собой полностью переработанные, значительно расширенные и существенно улучшенные версии глав 5-9 седьмого издания. В частности, сведения о типах (известных также как домены) были вынесены в отдельную главу (глава 5), а ма териал, который относится к проблеме целостности (глава 9), был заново проду ман и полностью переработан. Автор спешит добавить, что изменения в этих гла вах являются следствием не пересмотра основополагающих концепций, а скорее пересмотра самого подхода, выбранного для их представления, на основании практического опыта преподавания этого материала для широкой аудитории.

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

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

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

Часть III. Главы 10-13 этой части представляют собой в основном откорректиро ванные версии глав 9-12 из предыдущего, седьмого издания. Но на уровне изло жения конкретных сведений в них внесены существенные изменения.

Примечание. И здесь необходимо дать некоторые дополнительные пояснения.

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

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

(Говоря об этом, следует признать, что многие преподаватели предпочитают из лагать сведения о сущностях и связях гораздо раньше. С учетом этого автор попы тался сделать главу 14 более или менее автономной, с тем чтобы преподаватели могли ввести ее в курс лекций, скажем, сразу же после главы 4.) Часть IV. Две главы этой части, 15 и 16, представляют собой полностью пересмот ренные, расширенные и дополненные версии глав 14 и 15 из седьмого издания.

В частности, теперь глава 16 включает тщательный анализ так называемых свойств ACID транзакций (а также некоторые довольно неожиданные выводы по этой теме).

Часть V. Глава 20 о наследовании типов и глава 23 о хронологических базах дан ных были полностью пересмотрены с учетом новейших исследований и разрабо ток в этих областях. Изменения, которые произошли в других главах, в основном представляют собой их корректировку, хотя внесены существенные уточнения в те пояснения и примеры, которые приведены в этих главах, а также повсеместно добавлен новый материал.

Часть VI. Главы 25 и 26 представляют собой улучшенные и дополненные версии глав 24 и 25 из седьмого издания. Глава 27 является новой.

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

Приложение Г — это существенно пересмотренная версия приложения А из шестого издания. Ответы к избранным упражнениям, которые в седьмом издании были приведены в соответствующих главах, теперь вынесены в отдельное приложение Д.

ОТЛИЧИТЕЛЬНЫЕ ОСОБЕННОСТИ ДАННОЙ КНИГИ

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

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

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

Ниже перечислены основные указанные темы.

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

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

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

Модель TransRelational™.

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

С этим связана еще одна важная мысль: как может быть известно читателю, автор недавно опубликовал вместе со своим коллегой Хью Дарвеном еще одну "предписывающую" книгу, Foundation for Future Database Systems: The Third Manifesto (в настоящей книге она указана в списке литературы как [З.З])2. Эта книга, сокращенно называемая ее авторами Кроме того, Третьему Манифесту посвящен Web-узел http://www.thethirc3manifesto.com. Большой объем дополнительного материала можно также найти по адресу http: / /www. dbdebunk. com.

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

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

Примечание. В [3.3] в иллюстративных целях решено использовать язык Tutorial D, и то же самое принято в данной книге. Язык Tutorial D разрабатывался таким образом, чтобы его синтаксис и семантика в основном не требовали дополнительных пояснений (сам этот язык можно неформально охарактеризовать как "подобный Паскалю").

Но когда отдельные его средства используются впервые, дается их описание, если в этом есть необходимость.

ЗАКЛЮЧИТЕЛЬНОЕ ЗАМЕЧАНИЕ

В завершение своих вступительных замечаний, автор хотел бы привести следующую немного отредактированную выдержку из собственного предисловия Бертрана Рассела (Bertrand Russell) к его словарю The Bertrand Russell Dictionary of Mind, Matter and Morals (ed. Lester E. Denonn) — Citadel Press, 1993 (любезное разрешение на ее перепечатку получено).

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

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

БЛАГОДАРНОСТИ

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

38 Предисловие к восьмому изданию Прежде всего, я должен поблагодарить моих друзей Дэвида Макговерна (David McGoveran) и Ника Тиндола (Nick Tindall) за их важный вклад в подготовку на стоящего издания; Дэвид подготовил первый вариант главы 22 по поддержке принятия решений, а Ник — первый вариант главы 27 по XML. К тому же я очень признателен моему другу и коллеге Хью Дарвену (Hugh Darwen), который оказал мне большую помощь (в разных формах) в работе со всеми теми частями рукопи си, которые касались языка SQL. Наградж Алур (Nagraj Alur) и Фабиан Паскаль (Fabian Pascal) предоставили мне большой объем технического вспомогательного материала. Особую благодарность я хочу выразить Стиву Тарену (Steve Tarin) за то, что он изобрел технологию, описанную в приложении А, и оказал мне значи тельную помощь в достижении ее полного понимания.

Кроме того, текст книги был заметно улучшен благодаря замечаниям слушателей семинаров, которые я веду на протяжении последних нескольких лет. Кроме того, на нее чрезвычайно положительное влияние оказали комментарии многих друзей и рецензентов, а также мои дискуссии с ними. В их числе следует прежде всего на звать Хью Дарвена (Hugh Darwen), компания IBM; Ги де Тре (Guy de Тгё), Гентский Университет; Карла Экберга (Carl Eckberg), Университет штата Сан-Диего;

Ченга Хсу (Cheng Hsu), Политехнический институт Ренселлера; Абдул-Рахмана Итани (Abdul-Rahman Itani), Университет Мичигана-Дирборна; Виджая Канабара (Vijay Kanabar), Бостонский Университет; Брюса О. Ларсена (Bruce О. Larsen), Технологический институт Стевенса; Дэвида Ливингстона (David Livingstone), Нортумберлендский университет в Ньюкасле; Дэвида Макговерена (David McGoveran), компания Alternative Technologies; Стива Миллера (Steve Miller), IBM; Фабиана Паскаля (Fabian Pascal), независимая консультационная компа ния; Мартина К. Соломона (Martin К. Solomon), Флоридский Атлантический университет; Стива Тарена (Steve Tarin), компания Required Technologies; и Ника Тиндола (Nick Tindall), IBM. Каждый из них просмотрел, по крайней мере, часть рукописи этого издания, предоставил технический материал или как-то иначе помог мне найти ответы на многие технические вопросы, поэтому я всем им очень благодарен.

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

И наконец, как всегда, выражаю свою признательность всем сотрудникам изда тельства Addison-Wesley, особенно Майте Суарес-Ривас (Maite Suarez-Rivas) и Кэтрин Харутуниан (Katherine Harutunian) за их поощрение и поддержку во время работы над проектом, а также моему редактору Элизабет Беллер (Elisabeth Beller) за ее безукоризненную работу.

Ж Д Е М ВАШИХ О ТЗЫ ВО В!

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

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

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

E-mail: WWW: [email protected] России: 115419, Москва, а/я Украины: 03150, Киев, а/я

ОСНОВНЫЕ ПОНЯТИЯ

Часть I состоит из четырех вводных глав.

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

В главе 2 в общих чертах представлена архитектура баз данных — так называемая архитектура ANSI/SPARC. На основе этого материала строятся все последующие главы книги.

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

В главе 4 дано краткое введение в стандартный реляционный язык SQL (точнее, SQL: 1999).

Базы данных и управление ими 1.1 Вводный пример 1.2 Общее определение системы баз данных 1.3 Общее определение базы данных 1.4 Назначение баз данных 1.5 Независимость от данных 1.6 Реляционные и другие системы 1.1. ВВОДНЫЙ ПРИМЕР Система баз данных — это, по сути, не что иное, как компьютеризированная система хранения однотипных записей. Саму же базу данных можно рассматривать как подобие электронной картотеки, т.е. хранилище или контейнер для некоторого набора файлов данных, занесенных в компьютер.

Пользователям этой системы предоставляется возможность выполнять (или передавать системе запросы на выполнение) множество различных операций над такими файлами, например:

добавлять новые пустые файлы в базу данных;

вставлять новые данные в существующие файлы;

получать данные из существующих файлов;

удалять данные из существующих файлов;

изменять данные в существующих файлах;

удалять существующие файлы из базы данных.

В качестве иллюстрации в табл. 1.1 приведена небольшая база данных, состоящая всего из одного файла под названием CELLAR (винный погреб). В этом файле хранятся данные о содержимом винного погреба. На рис. 1.1 показан пример выполнения операции 44 Часть I. Основные понятия выборки и данные, возвращаемые с помощью этой операции. (Операции над базами данных, имена файлов и т.п. в этой книге для наглядности пишутся прописными буквами, хотя на практике часто удобнее использовать строчные. В большинстве СУБД допускаются оба варианта.) На рис. 1.2 приведены примеры операций вставки, удаления и обновления для базы данных винного погреба. Эти примеры почти не требуют пояснений. В других главах этой книги приведены примеры добавления и удаления файлов.

Таблица 1.1. Содержимое файла CELLAR Рис. 1.1. Пример выборки информации из базы данных На основании данных, приведенных в табл. 1.1 и на рис. 1.1 и 1.2, можно сделать приведенные ниже выводы.

1. Примеры запросов на выборку, вставку, удаление и обновление, приведенных на рис. 1.1 и 1.2, представлены с помощью операторов SELECT, INSERT, DELETE и UPDATE специального языка баз данных, называемого SQL. Язык SQL был первоначально разработан компанией IBM, а в настоящее время поддерживается большинством коммерческих СУБД, представленных на рынке, и является официальным стандартом языка для работы с реляционными базами данных. Поэтому в главе представлен общий обзор стандарта SQL, а в большинстве последующих глав включен раздел "Средства языка SQL" с описанием тех аспектов стандарта, которые относятся к теме соответствующей главы.

Название SQL вначале было аббревиатурой, образованной от Structured Query Language (язык структурированных запросов), и его было принято произносить как "сиквел". Сейчас, когда язык стал стандартом, SQL— это уже не аббревиатура, а обычное название, которое произносится как "эс-кью-эл". В дальнейшем в этой книге предполагается именно такой вариант произношения.

РИС. 1.2. Примеры операций вставки, удаления и обновления 2. Заметим, что в языке SQL для операции обновления используется ключевое слово UPDATE, обозначающее именно операцию модификации данных (см. рис. 1.2). Это в некоторых случаях может привести к недоразумениям, поскольку термин "обно вить" (update) используется также по отношению к операциям вставки (INSERT), удаления (DELETE) И обновления (UPDATE) В целом, как к группе операций. В дан ной книге мы будем различать эти два понятия, используя строчные буквы при запи си общего понятия и прописные буквы, когда будет подразумеваться именно опера ция обновления UPDATE.

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

3. В языке SQL компьютерные файлы, такие как CELLAR в табл. 11, называются таб лицами (по очевидным причинам). Строки (row) подобных таблиц соответствуют записям файла, а столбцы (column) можно рассматривать как поля этих записей.

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

46 Часть I. Основные понятия 4. Для простоты в примере таблицы CELLAR по умолчанию предполагается, что в столбцах WINE и PRODUCER содержатся строковые данные, а во всех остальных столбцах — целочисленные данные. Но, как правило, столбцы могут содержать данные произвольной сложности. В частности, таблица CELLAR может быть до полнена для включения в нее следующих столбцов (а также столбцов многих дру LABEL. Фотография этикетки винной бутылки.

REVIEW. Текст отзыва о качестве вина, полученный из определенного винного MAP. Карта той местности, где было изготовлено это вино.

NOTES. Звукозапись, содержащая комментарии о вкусе вина.

По очевидным причинам, в большинстве примеров этой книги используются только очень простые типы данных, но следует учитывать, что всегда существует возможность применять гораздо более сложные структуры данных. Вопросы, касающиеся типов данных (data type) столбцов, более подробно будут обсуждаться в 5. Столбец BIN# является первичным ключом (primary key) таблицы CELLAR (подра зумевается, что любые две строки этой таблицы никогда не будут содержать одно и то же значение поля BIN#). Для выделения в таблицах столбцов первичного ключа мы обычно будем использовать двойное подчеркивание (как в табл. 1.1).

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

1.2. ОБЩЕЕ ОПРЕДЕЛЕНИЕ СИСТЕМЫ БАЗ ДАННЫХ

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

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

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

Рис. 1-3. Упрощенная схема системы баз данных Данные Системы с базами данных применяются как на самых малых компьютерах, так и на крупнейших мэйнфреймах. Несомненно, предоставляемые каждой конкретной системой средства в значительной мере зависят от мощности и возможностей базовой машины. В частности, на больших вычислительных машинах применяются в основном многопользовательские системы ("большие системы"), а на малых компьютерах, как правило, — однопользовательские системы ("малые системы"). Однопользовательская система (single-user system) — это система, в которой к базе данных может получить доступ одновременно только один пользователь, а многопользовательская система (multi-user system) — это такая система, в которой к базе данных могут получить доступ сразу несколько пользователей. Как показано на рис. 1.3, исходя из соображений общности, мы обычно будем изучать именно второй вид систем, хотя с точки зрения пользователей между этими системами фактически не существует большого различия, поскольку основная цель многопользовательских систем состоит в том, чтобы позволить каждому отдельному пользователю работать с ней так, как если бы он работал с однопользовательской системой. Различия между этими двумя видами систем проявляются 48 Часть I. Основные понятия в их внутренней структуре и потому практически не видны конечному пользователю (о чем речь пойдет в части IV этой книги, особенно в главе 16).

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

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

Под понятием интеграции данных подразумевается возможность представить базу данных как объединение нескольких отдельных файлов данных, полностью или частично исключающее избыточность хранения информации. Например, база данных может содержать файл EMPLOYEE, включающий имена сотрудников, адреса, отделы, данные о зарплате и т.д., и файл ENROLLMENT, содержащий сведения о регистрации сотрудников на курсах обучения (рис. 1.4). Допустим, что для контроля процесса обучения необходимо знать отдел каждого зачисленного на курсы сотрудника. Совершенно очевидно, что нет необходимости включать такую информацию в файл ENROLLMENT, поскольку ее всегда можно получить из файла Рис. 1.4. Файлы EMPLOYEE И ENROLLMENT Под понятием разделяемое™ данных подразумевается возможность использования несколькими различными пользователями отдельных элементов, хранимых в базе данных. Имеется в виду, что каждый из пользователей сможет получить доступ к одним и тем же данным, возможно, даже одновременно (параллельный доступ). Такое разделение данных, с параллельным или последовательным доступом, частично является следствием того факта, что база данных имеет интегрированную структуру. В примере, приведенном на рис. 1.4, информация об отделе в файле EMPLOYEE может совместно использоваться сотрудниками отдела кадров и отдела обучения. (Если база данных не является разделяемой, то ее иногда называют личной базой или базой данных специального назначения.) Одним из следствий упомянутых выше характеристик базы данных (интеграции и разделяемости) является то, что каждый конкретный пользователь обычно имеет дело лишь с небольшой частью всей базы данных, причем обрабатываемые различными пользователями части могут произвольным образом перекрываться. Иначе говоря, каждая база данных воспринимается ее различными пользователями по-разному. Фактически, даже те два пользователя базы данных, которые работают с одними и теми же частями базы данных, могут иметь значительно отличающиеся представления о них. Более подробное обсуждение этого вопроса приводится далее, в разделе 1.5 и в следующих главах (в частности, в главе 10).

В разделе 1.3 мы продолжим обсуждение свойств элементов данных, хранимых в системе баз данных.

Аппаратное обеспечение К аппаратному обеспечению системы относится следующее:

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

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

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

Программное обеспечение Между собственно физической базой данных (т.е. данными, которые реально хранятся на компьютере) и пользователями системы располагается уровень программного обеспечения, который можно называть по-разному: диспетчер базы данных (database manager), сервер базы данных (database server) или, что более привычно, система управления базами данных, СУБД (DataBase Management System — DBMS). Все запросы пользователей на получение доступа к базе данных обрабатываются СУБД. Все имеющиеся средства добавления файлов (или таблиц), выборки и обновления данных в этих файлах или таблицах также предоставляет СУБД. Основная задача СУБД — дать пользователю базы данных возможность работать с ней, не вникая во все подробности работы на уровне аппаратного обеспечения. (Пользователь СУБД более отстранен от этих подробностей, чем прикладной программист, применяющий языковую среду программирования.) Иными словами, СУБД позволяет конечному пользователю рассматривать базу данных как объект более высокого уровня по сравнению с аппаратным обеспечением, а также предоставляет в его распоряжение набор операций, выражаемых в терминах языка высокого уровня (например, набор операций, которые можно выполнять с помощью языка SQL, упомянутого выше, в разделе 1.1). Далее в книге будут подробно описаны обе указанные функции СУБД.

50 Часть I. Основные понятия Необходимо отметить еще две описанные ниже особенности.

СУБД— это наиболее важный, но не единственный программный компонент системы. В числе других компонентов можно назвать утилиты, средства разра ботки приложений, средства проектирования, генераторы отчетов и диспетчер транзакций (transaction manager), или диспетчер обработки транзакций (transaction processing monitor — ТР monitor). Эти компоненты описаны более подробно в гла вах 2, 3, особенно в главах 15 и 16.

Термин СУБД также часто используется в отношении конкретных программных продуктов конкретных изготовителей, например, таких как DB2 Universal Database компании IBM. Иногда в тех случаях, когда конкретная копия подобного продукта устанавливается для работы на определенном компьютере, используется термин экземпляр. Безусловно, необходимо строго различать эти два понятия.

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

(Проблема, естественно, заключается в том, что если СУБД называют базой данных, как же тогда называть саму базу данных?) Читатель, будь внимателен!

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

Первая группа — прикладные программисты, которые отвечают за написание при кладных программ, использующих базу данных. Для этих целей применимы такие языки, как COBOL, PL/I, C++, Java или какой-нибудь высокоуровневый язык четвертого поколения (см. главу 2). Прикладные программы получают доступ к ба зе данных посредством выдачи соответствующего запроса к СУБД (обычно это не который оператор SQL). Подобные программы могут быть простыми пакетными приложениями или же интерактивными приложениями, предназначенными для поддержки работы конечных пользователей (см. следующий абзац). В последнем случае они предоставляют пользователям непосредственный оперативный доступ к базе данных через рабочую станцию, терминал или персональный компьютер.

Большинство современных приложений относится именно к этой категории.

Вторая группа — конечные пользователи, которые работают с системой баз данных в интерактивном режиме, как указано в предыдущем абзаце. Конечный пользова тель может получать доступ к базе данных, применяя одно из интерактивных при ложений, упомянутых выше, или же интерфейс, интегрированный в программное обеспечение самой СУБД. Безусловно, подобный интерфейс также поддержи вается интерактивными приложениями, но эти приложения не создаются пользователями-программистами, а являются встроенными в СУБД. Большин ство СУБД включает по крайней мере одно такое встроенное приложение, а именно — процессор языка запросов, позволяющий пользователю в диалоговом режиме вводить запросы к базе данных (их часто иначе называют предложениями или командами), например, с операторами SELECT или INSERT. Язык SQL представляет собой типичный пример языка запросов к базе данных. (Общепринятый термин язык запросов не совсем точно отражает рассматриваемое понятие, поскольку слово запрос подразумевает лишь выборку информации, в то время как с помощью этого языка выполняются также операции обновления, вставки, удаления и др.) Кроме языка запросов, в большинстве систем дополнительно предоставляются специализированные встроенные интерфейсы, в которых пользователь в явном виде не использует предложения, или команды с такими операторами, как SELECT и INSERT. Работа с базой данных осуществляется за счет выбора пользователем необходимых элементов меню или заполнения требуемых полей в предоставленных формах. Такие некомандные интерфейсы, основанные на меню и формах, облегчают работу с базами данных для тех, кто не имеет опыта работы с информационными технологиями (или ИТ; часто употребляется также сокращение ИС — информационные системы; эти понятия практически эквивалентны). Командный интерфейс, т.е. язык запросов, напротив, требует некоторого профессионального опыта работы с ИТ (но, безусловно, не такого большого, какой необходим для написания прикладных программ на языке программирования, подобном COBOL). Однако командный интерфейс более гибок, чем некомандный, к тому же языки запросов обычно включают определенные функции, отсутствующие в интерфейсах, основанных на использовании меню или форм.

Третья группа (на рис. 1.3 не показана) — администраторы базы данных, ИЛИ АБД.

Обсуждение функций администраторов баз данных и связанных с ними (что очень важно) функций администрирования данных, отложим до раздела 1.4 и главы (раздел 2.7).

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

1.3. ОБЩЕЕ ОПРЕДЕЛЕНИЕ БАЗЫ ДАННЫХ

Перманентные данные Обычно данные в базе данных называют перманентными или постоянно хранимыми (хотя иногда на самом деле они недолго остаются таковыми!). Под словом перманентные (persistent) подразумеваются данные, которые отличаются от других, более изменчивых данных, таких как промежуточные результаты, входные и выходные данные, управляющие операторы, рабочие очереди, программные управляющие блоки и вообще все данные, временные (transient) по своей сути. Точнее говоря, можно утверждать, что данные в базе являются перманентными, поскольку после того как они были приняты средствами СУБД для помещения в базу, их последующее удаление возможно лишь при использовании соответствующего явного запроса к базе данных, но не в результате какого-либо побочного эффекта от выполнения некоторой программы. Подобный взгляд на понятие перманентности позволяет точнее определить терминбаза данных.

База данных — это некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

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

1. Промышленная компания.

4. Университет.

5. Министерство.

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

1. Данные о продукции.

2. Бухгалтерские данные.

3. Данные о пациентах.

4. Данные о студентах.

5. Данные о планируемой деятельности.

Примечание. В первых шести изданиях этой книги вместо термина перманентные данные использовался термин операционные данные. Старый термин первоначально акцентировал внимание на особом значении оперативных, или производственных, приложений баз данных, т.е. рутинных, часто выполняющихся приложений, предназначенных для поддержки повседневной работы предприятия (например, приложений для поддержки операций зачисления и списания средств на счетах в банковской системе). Для среды такого рода в последнее время используется термин оперативная обработка транзакций (On-Line Transaction Processing— OLTP). Однако теперь базы данных все чаще применяются и в приложениях другого рода, например, в приложениях поддержки принятия решений (decision support), и термин операционные данные для них уже не подходит.

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

Сущности и связи Рассмотрим более подробно пример некоторой промышленной компании (допустим, она имеет название KnowWare, Inc.). Обычно подобному предприятию требуется записывать информацию об имеющихся проектах (Projects), используемых в этих проектах деталях (Parts), поставщиках (Suppliers) деталей, складах (Warehouses), на которых хранятся детали, служащих (Employees), работающих над проектами и т.д. Проекты, детали, поставщики и т.д. представляют собой основные сущности (entity), о которых компании KnowWare, Inc. необходимо хранить информацию. В теории баз данных термин сущность обычно используется для обозначения любого различимого объекта, который может быть представлен в базе данных (рис. 1.5).

Рис. 1.5. Пример диаграммы "сущность-связь" (ER-диаграммы) для базы данных компании KnowWare, Inc.

Кроме этих основных сущностей (в данном примере это поставщики, детали и т.д.), имеются еще и связи (relationship) между ними, которые объединяют эти основные сущности. На рис. 1.5 связи представлены ромбами с соединительными линиями. Например, между поставщиками и деталями существует связь SP (сокращение от Shipments/Parts):

каждый поставщик поставляет определенные детали, и наоборот, каждая деталь поставляется определенными поставщиками. (Точнее, каждый поставщик поставляет определенные виды деталей, и каждый вид деталей поставляется определенными поставщиками.) Аналогично, детали используются в проектах, а для реализации проектов требуются детали (связь PJ — сокращение от Parts/proJects); детали хранятся на складах, а склады хранят детали (связь WP — сокращение от Warehouses/Parts) и т.д. Обратите внимание, что эти связи — бинарные (или двухсторонние), т.е. их можно прослеживать в любом направлении. В частности, используя связь SP между поставщиками и деталями, можно ответить на следующие вопросы:

задан поставщик, и требуется определить поставляемые им детали;

задана деталь, и необходимо найти поставщиков, предоставляющих такую деталь.

54 Часть I. Основные понятия Очень важно то, что эта связь (как и другие связи, представленные на рис. 1.5) является такой же неотъемлемой составляющей данных предприятия, как и основные сущности. Поэтому связи должны быть представлены в базе данных наравне с основными сущностями предметной области1.

Следует отметить, что на рис. 1.5 приведен пример информационной структуры, которую принято называть (по очевидным причинам) диаграммой "сущность—связь" (сокращенно ER-диаграммой). Более подробно такие схемы рассматриваются в главе 14.

Рис. 1.5 может также служить иллюстрацией для многих других важных понятий, описанных ниже.

Хотя большинство связей на этой диаграмме объединяют два типа сущностей (т.е.

они являются бинарными связями), это вовсе не означает, что все связи должны быть бинарными. В примере есть одна связь (SPJ), охватывающая три типа сущностей (Suppliers, Parts и Projects). Это пример тернарной (трехсторонней) связи. Интерпретация данной связи такова: определенные поставщики поставляют определенные детали для определенных проектов. Обратите особое внимание на то, что в общем случае такая тернарная связь ("поставщики поставляют детали для проектов") не эквивалентна простой комбинации из трех бинарных связей:

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

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

в) "Разводные гаечные ключи используются в Манхэттенском проекте".

г) "Манхэттенский проект снабжается Смитом".

Зная только утверждения б, в и г, мы не сможем доказать справедливость утверждения а. Точнее, зная, что справедливы утверждения б, в и г, мы можем лишь сделать заключение, что Смит поставляет разводные гаечные ключи для какого-то проекта (скажем, проекта Jz), что какой-то поставщик (скажем, поставщик Sx) поставляет разводные гаечные ключи для Манхэттенского проекта и что Смит поставляет какую-то деталь (скажем, деталь PY) для Манхэттенского проекта.

Однако мы не можем точно утверждать, что поставщик Sx — это Смит, деталь PY — это разводной гаечный ключ, а проект Jz — это Манхэттенский проект. Ложные Характерной особенностью реляционных баз данных (см. раздел 1.6) является то, что основные сущности и связи между ними представлены с помощью отношений (relation) или, иными словами, с помощью таблиц, подобных показанной в табл. 1.1. Но следует учитывать, что термин связь (relationship), который используется в текущем разделе, и термин отношение, применяемый в контексте реляционных баз данных, обозначают разные понятия.

Применяемый в оригинале англоязычный термин statement имеет два разных значения: в данном случае он указывает на утверждение, касающееся некоторого факта (которое в логике принято называть высказыванием; см. подраздел "Данные и модели данных" ниже в этом разделе), а в другом контексте может служить синонимом термина command (команда).

выводы, сделанные на основании неполной информации, называются дефектом соединения (connection trap).

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

3. Вообще говоря, для заданного набора типов сущностей может существовать любое количество связей. В представленной на рис. 1.5 диаграмме присутствуют две раз личные связи между сущностями Projects и Employees: первая (EJ) представ ляет тот факт, что служащие заняты в проектах, а вторая (MJ) — что служащие управляют проектами.

Теперь мы убедились, что связь можно понимать как сущность особого типа. Если сущность определена как "нечто, о чем необходимо хранить информацию", то понятие связи вполне подходит под такое определение. Например, связь "деталь Р4 находится на складе W8" — это сущность, о которой может потребоваться записать некоторую информацию, например, зафиксировать в базе данных количество указанных деталей. Благодаря тому, что мы не проводим ненужных различий между сущностями и связями, достигаются определенные преимущества (их описание выходит за рамки настоящей главы). Поэтому в данной книге связи будут рассматриваться как особый вид сущности.

Свойства Как было только что отмечено, сущность — это то, о чем необходимо хранить информацию. Отсюда следует, что сущности (а значит, и связи) имеют некоторые свойства (properties), соответствующие тем данным о них, которые необходимо хранить в базе.

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

В общем случае свойства могут быть как простыми, так и сложными, причем настолько простыми или сложными, насколько это потребуется. Например, свойство "местонахождение поставщика" — относительно простое: оно состоит только из названия города и может быть описано как простая символьная строка. В противоположность этому, сущность "склад" может иметь свойство "схема этажей" с достаточно сложной структурой, включающей архитектурный план здания, дополненный соответствующим текстовым описанием. Как отмечалось в разделе 1.1, ко времени написания этой книги лишь немногие СУБД поддерживали работу с такими сложными свойствами, как изображения с текстовым описанием. Мы еще возвратимся к данному вопросу позже в этой книге (в частности, в главах 5, 6, 26 и 27), а пока в большинстве случаев (за исключением тех, 56 Часть I. Основные понятия в которых приходится явно учитывать различия между простыми и сложными свойствами) будем полагать, что все свойства являются простыми и их можно представить простыми типами данных: числами, строками, датами, отметками времени и т.п.

Данные и модели данных Существует и другой, не менее важный, подход к трактовке данных и баз данных.

Слово данные (data) происходит от латинского слова "дано" (напрашивается продолжение "требуется доказать"). Отсюда следует, что данные на самом деле являются заданными фактами, из которых можно логически вывести другие факты. (Получение производных фактов из заданных — это именно то, что выполняет СУБД, обслуживая запросы пользователя.) "Заданный факт", в свою очередь, соответствует тому, что в логике называется истинным высказыванием. Например, высказывание "Поставщик с номером S находится в Лондоне" вполне может оказаться истинным. Высказыванием в логике называется такое утверждение, которое может быть недвусмысленно определено как истинное или ложное. Например, "Вильям Шекспир написал Гордость и предубеждение" — это высказывание (как видно, ложное). Отсюда следует, что в действительности база данных — это множество истинных высказываний [ 1.2].

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

1. Данные представлены посредством строк в таблицах3, и эти строки могут быть не посредственно интерпретированы как истинные высказывания. Например, строку с номером ячейки погреба (поле BIN#), равным 72 (см. табл. 1.1), можно очевид ным образом интерпретировать как следующее истинное высказывание:

"В ячейке 72 находятся две бутылки вина Zinfandel, выпущенные компанией Rafanelli в 1999 году, которые будут готовы к употреблению в 2007 году".

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

"Некоторые бутылки вина Zinfandel будут готовы к употреблению в 2 007 году".

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

Однако реляционная модель — не единственная возможная модель данных. Существуют и другие модели (раздел 1.6), хотя многие из них отличаются от реляционной модели только тем, что они в определенной степени приспособлены для специальных случаев, а не строго основаны на формальной логике, в отличие от реляционной модели. Возникает вопрос: что же такое модель данных? Это понятие можно определить, руководствуясь [1.1] (но в ином изложении), как показано ниже.

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

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

Короче говоря, модель — это то, о чем пользователи должны знать, а реализация -это то, чего пользователи не должны знать.

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

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

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

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

58 Часть I. Основные понятия Модель данных во втором значении подобна конкретной программе, написанной на таком языке. Иначе говоря, модель данных во втором значении использует средства, предоставляемые некоторой моделью (рассматриваемой в первом значении) и применяет их для решения конкретной проблемы. Ее можно рассматривать как некоторое конкретное приложение некоторой модели в первом значении.

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

1.4. НАЗНАЧЕНИЕ БАЗ ДАННЫХ Почему так широко используются системы с базами данных? Какие преимущества получает пользователь при работе с ними? В некоторой степени ответ зависит от того, о какой системе идет речь — однопользовательской или многопользовательской (точнее будет сказать, что многопользовательские системы предоставляют многочисленные дополнительные преимущества). Сначала рассмотрим случай однопользовательской системы.

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

Компактность. Нет необходимости в создании и ведении, возможно, весьма объемистых бумажных картотек.

Быстродействие. Компьютер может выбирать и обновлять данные гораздо быстрее человека. В частности, с его помощью можно быстро получать ответы на произ вольные вопросы, возникающие в процессе работы (например, "Какого вина у нас сейчас больше — Zinfandel или Pinot Noir?"), не затрачивая времени на визуаль ный осмотр или поиск вручную.

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

Актуальность. В случае необходимости под рукой в любой момент имеется точная, свежая информация.

Защита. Данные могут быть лучше защищены от случайной потери и несанкционированного доступа.

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

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

Это— администратор данных, или сокращенно АД, уже упоминавшийся в разделе 1.2.

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

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

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

Работа АБД заключается в создании самих баз данных и организации технического контроля, необходимого для осуществления решений, принятых администратором данных.

АБД несет также ответственность за обеспечение необходимого быстродействия системы и ее техническое обслуживание. Обычно у АБД есть штат из системных программистов и технических ассистентов (т.е. на практике функции АБД часто выполняет группа из нескольких человек, а не один служащий). Однако для простоты удобнее считать, что администратор базы данных — один человек. Более подробно функции АБД описаны в главе 2.

Преимущества подхода, предусматривающего использование базы данных Рассмотрим преимущества использования баз данных, связанные с наличием централизованного управления.

Возможность совместного доступа к данным Этот вопрос уже обсуждался в разделе 1.2, но для полноты проанализируем его еще раз. Совместный доступ к данным означает не только возможность доступа к ним с помощью нескольких существующих приложений базы данных, но и возможность разработки новых приложений для работы с этими же данными. Другими 60 Часть I. Основные понятия словами, требования новых приложений по доступу к данным могут быть удовлетворены без необходимости добавления новых данных в базу.

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

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

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

Устранение противоречивости данных (до некоторой степени) В действительности это следует из предыдущего пункта. Возьмем пример из жизни. Пусть служащий с табельным номером ЕЗ, работающий в отделе с номером D8, представлен двумя различными записями в базе данных. Предположим, что в СУБД не учтено это дублирование (т.е. избыточность данных не контролируется). Тогда рано или поздно обязательно возникнет ситуация, при которой эти две записи перестанут быть согласованными, после того как одна из них будет изменена, а другая — нет. В этом случае база данных станет противоречивой.

Ясно, что противоречивая база данных будет предоставлять пользователю неправильную, противоречивую информацию.

Также очевидно, что если какой-либо факт представлен только одной записью (т.е. избыточность отсутствует), то противоречия исключены. Противоречий можно также избежать, если избыточность не исключается, а контролируется (и это соответствующим образом предусмотрено в СУБД). Тогда СУБД сможет гарантировать, что с точки зрения пользователя база данных никогда не будет противоречивой. Данная гарантия обеспечивается тем, что если обновление вносится в одну запись, то оно автоматически будет распространено на все остальные. Такой процесс называется распространением обновлений (propagating Возможность поддержки транзакций Транзакция (transaction) — это логическая единица работы (точнее, логическая единица работы базы данных), обычно включающая несколько операций базы данных (в частности, несколько операций модификации данных). Стандартный пример — перевод некоторой суммы денег со счета А на счет В. Очевидно, что в данном случае необходимы два изменения: списание некоторой суммы со счета А и зачисление ее на счет В. Если пользователь укажет, что оба изменения входят в одну и ту же транзакцию, то система сможет реально гарантировать, что либо будут выполнены оба эти изменения, либо не будет выполнено ни одно из них, если до завершения процесса внесения изменений в системе произойдет сбой (скажем, из-за перерыва в подаче электроэнергии).

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

Обеспечение целостности данных Задача обеспечения целостности заключается в гарантированной поддержке правильности данных в базе (насколько это возможно). Противоречие между двумя записями, представляющими один "факт", является примером утраты целостности данных (см. обсуждение этого вопроса выше в данном разделе). Конечно, эта конкретная проблема может возникнуть лишь при наличии избыточности в хранимых данных. Но даже если избыточность отсутствует, база данных может содержать неправильную информацию. Например, в базе данных может быть указано, что сотрудник отработал 400 рабочих часов в неделю вместо 40, или зафиксирована его принадлежность к отделу, которого не существует. Централизованное управление базой данных позволяет избежать подобных проблем (насколько это вообще возможно). Для этого администратор данных определяет (а администратор базы данных реализует) ограничения целостности (integrity constraints), которые будут применяться при любой попытке внести какие-либо изменения в соответствующие данные.

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

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

Организация защиты данных Благодаря полному контролю над базой данных администратор базы данных (безусловно, в соответствии с указаниями администратора данных) может обеспечить доступ к ней только через определенные каналы. Для этой цели могут устанавливаться ограничения защиты (security constraints), или правила, которые будут контролироваться при любой попытке доступа к конфиденциальным данным. Можно установить 62 Часть I. Основные понятия различные правила для разных типов доступа (выборка, вставка, удаление и т.д.) к каждому из элементов информации в базе данных. Однако следует отметить, что при отсутствии таких правил безопасность данных подвергается большему риску, чем в обычной (разобщенной) файловой системе. Следовательно, централизованная природа системы баз данных в определенном смысле требует также наличия надежной системы защиты.

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

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

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

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

1.5. НЕЗАВИСИМОСТЬ ОТДАННЫХ Независимость от данных может быть реализована на двух уровнях: физическом и логическом [1.3], [1.4]. Однако на данном этапе нас интересует только физическая независимость. Поэтому неуточненный термин независимость от данных мы пока будем понимать лишь как физическую независимость от данных. (Необходимо отметить, что термин независимость от данных не совсем подходящий — он не отражает достаточно точно сущность происходящего. Но поскольку традиционно используется именно этот термин, последуем общему правилу.) Проще всего разобраться в понятии независимости от данных на примере той ситуации, когда независимость от данных отсутствует. Приложения, реализованные в старых системах (дореляционные, или созданные до появления систем баз данных), в той или иной мере зависимы от данных. Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями приложения. Более того, сведения об организации данных и способе доступа к ним встроены в саму логику и программный код приложения. Например, предположим, что в некотором приложении используется файл EMPLOYEE (см. рис. 1.4). Исходя из соображений производительности решено, что этот файл необходимо проиндексировать по полю "имя служащего" (см. приложение Г).

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