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