- •Содержание
- •Глава 1 Концепция баз данных 6
- •Глава 2 Модели данных 12
- •Глава 3 Реляционная модель данных 24
- •Глава 4 Элементы языка sql 42
- •Глава 5 Проектирование баз данных 66
- •Глава 6 Функции субд и системы обработки транзакций 81
- •Глава 7 Технологии, модели и архитектура систем обработки данных 88
- •Глава 1 Концепция баз данных
- •1.1 Данные и эвм
- •1.2 Поколения субд и направления исследований
- •1.3 Терминология в субд
- •1.4 Вопросы для самоконтроля к главе 1
- •Глава 2 Модели данных
- •2.1. Классификация моделей данных
- •2.2 Основные особенности систем, основанных на инвертированных списках
- •2.2.1 Структуры данных
- •2.2.2 Манипулирование данными
- •2.2.3 Ограничения целостности
- •2.3 Иерархические модели
- •2.3.1. Иерархические структуры данных
- •2.3.2 Манипулирование данными
- •2.3.3 Ограничения целостности
- •2.4 Сетевые модели
- •2.4.1 Сетевые структуры данных
- •2.4.2 Манипулирование данными
- •2.4.3 Ограничения целостности
- •2.5 Физические модели организации баз данных
- •Файловые структуры, используемые для хранения данных в бд
- •Модели страничной организации данных в современных бд
- •Этапы доступа к бд
- •Вопросы и упражнения для самоконтроля к главе 2
- •Глава 3 Реляционная модель данных
- •3.1 Базовые понятия реляционных баз данных
- •3.1.1. Тип данных
- •3.1.2. Домен
- •3.1.3 Схема отношения, схема базы данных
- •3.1.4 Кортеж, отношение, ключи
- •3.1.5 Связи в реляционных базах данных
- •3.2 Фундаментальные свойства отношений
- •3.2.1 Отсутствие кортежей-дубликатов
- •3.2.2 Отсутствие упорядоченности кортежей
- •3.2.3 Отсутствие упорядоченности атрибутов
- •3.2.4 Атомарность значений атрибутов
- •3.3. Характеристика реляционной модели данных
- •3.4 Трехзначная логика (3vl)
- •3.5 Реляционная алгебра
- •Эквисоединение. Наиболее важным частным случаем -соединения является случай, когда есть просто равенство. Синтаксис эквисоединения:
- •3.6 Особенности операций реляционной алгебры
- •Реляционное исчисление
- •Вопросы и упражнения для самоконтроля к главе 3
- •Глава 4 Элементы языка sql
- •4.1 История языка sql
- •4.2 Структура языка sql
- •Ddl (Data Definition Language) - операторы определения объектов базы данных:
- •Dml (Data Manipulation Language) - операторы манипулирования данными:
- •Dcl (Data Control Language) - операторы контроля данных, защиты и управления данными:
- •4.3 Создание запроса с помощью оператора select
- •4.3.1 Создание простых запросов
- •4.3.2. Агрегирование данных в запросах
- •4.3.3 Формирование запросов на основе соединения таблиц
- •4.3.4 Формирование структур вложенных запросов
- •Простые подзапросы
- •4.3.4.2 Соотнесенные (коррелированные) подзапросы
- •Запросы с использованием кванторов
- •4.3.5 Объединение нескольких запросов в один
- •4.3.6 Синтаксис оператора select
- •4.4 Операторы манипулирования данных
- •4.4.1 Оператор удаления данных delete
- •4.4.2 Оператор вставки данных insert
- •4.4.3 Оператор обновления данных update
- •Операторы определения объектов базы данных
- •4.5.1 Операторы определения таблицы
- •4.5.2 Оператор определения представлений create view
- •Операторы контроля данных, защиты и управления данными
- •4.6.1 Операторы управления привилегиями
- •4.6.2 Операторы управления транзакциями
- •4.6.3 Проблемы параллельной работы транзакций
- •Вопросы и упражнения для самоконтроля к главе 4
- •Глава 5 Проектирование баз данных
- •5.1 Проектирование реляционных бд с использованием принципов нормализации
- •Проектирование реляционных бд с использованием семантических моделей
- •5.2.1 Применение семантических моделей при проектировании
- •5.2.2. Основные понятия модели Entity-Relationship
- •5.2.3 Пример разработки простой er-модели
- •Практические рекомендации по проектированию бд
- •Вопросы и упражнения для самоконтроля к главе 5
- •Глава 6 Функции субд и системы обработки транзакций
- •6.1 Основные функции субд
- •1.Непосредственное управление данными во внешней памяти
- •2. Управление буферами оперативной памяти
- •3. Управление транзакциями
- •4. Журнализация
- •5. Поддержка языков бд
- •Системы обработки транзакций
- •6.2.1 Oltp-системы
- •6.2.2 Olap -системы
- •6.2.3 Мониторы транзакций
- •Архитектура субд
- •6.4 Пользователи бд
- •6.4 Вопросы и упражнения для самоконтроля по главе 6
- •Глава 7 Технологии, модели и архитектура систем обработки данных
- •7.1 Технологии и модели архитектуры «клиент-сервер»
- •7.2 Распределенная обработка данных
- •Аспекты сетевого взаимодействия
- •Технология распределенной бд (технология star)
- •Технология тиражирования данных
- •7.3 Концепция активного сервера в модели dbs
- •7.4 Вопросы и упражнения для самоконтроля к главе 7
- •Литература
3.2.3 Отсутствие упорядоченности атрибутов
Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута – имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной форме определения схемы отношения.
3.2.4 Атомарность значений атрибутов
Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения). Принято говорить, что в реляционных базах данных допускаются только нормализованные отношения или отношения, представленные в первой нормальной форме. Нормализованные отношения составляют основу классического реляционного подхода к организации баз данных. Они обладают некоторыми ограничениями (не любую информацию удобно представлять в виде плоских таблиц), но существенно упрощают манипулирование данными.
3.3. Характеристика реляционной модели данных
Наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит Дейту К., который воспроизводит ее (с различными уточнениями) практически во всех своих книгах. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.
В структурной части реляционной модели данных фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. По сути дела, в предыдущих двух параграфах мы рассматривали именно понятия и свойства структурной составляющей реляционной модели.
В манипуляционной части реляционной модели данных утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.
В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД.
Первое требование называется требованием целостности сущностей. Объектам или сущностям реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Как видно из предыдущего раздела, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.
Второе требование называется требованием целостности по ссылкам и является более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной БД сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). При правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) первичный ключ - ОТД_НОМЕР и СОТРУДНИКИ ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) первичный ключ - СОТР_НОМЕР.
Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Для нашего примера это означает, что если для сотрудника указан номер отдела, то этот отдел должен существовать.
Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. С целостностью по ссылкам дела обстоят несколько более сложно.
Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа из отношения, на которое ведет ссылка?
Существуют три подхода, каждый из которых поддерживает целостность по ссылкам:
1. запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа);
2. при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным;
3. каскадное удаление, состоящее в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по ссылкам для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.