Данные и ЭВМ

Глава 1 Концепция баз данных

Содержание

Содержание. 4

Глава 1 Концепция баз данных. 6

1.1 Данные и ЭВМ... 6

1.2 Поколения СУБД и направления исследований. 8

1.3 Терминология в СУБД.. 10

1.4 Вопросы для самоконтроля к главе 1. 12

Глава 2 Модели данных. 12

2.1. Классификация моделей данных. 12

2.2 Основные особенности систем, основанных на инвертированных списках. 14

2.2.1 Структуры данных. 14

2.2.2 Манипулирование данными. 14

2.2.3 Ограничения целостности. 15

2.3 Иерархические модели. 15

2.3.1. Иерархические структуры данных. 15

2.4 Сетевые модели. 16

2.4.1 Сетевые структуры данных. 16

2.4.2 Манипулирование данными. 17

2.4.3 Ограничения целостности. 17

2.5 Физические модели организации баз данных. 17

2.5.1 Файловые структуры, используемые для хранения данных в БД.. 19

2.5.2 Модели страничной организации данных в современных БД.. 21

2.5.3 Этапы доступа к БД.. 22

2.6 Вопросы и упражнения для самоконтроля к главе 2. 24

Глава 3 Реляционная модель данных. 24

3.1 Базовые понятия реляционных баз данных. 24

3.1.1. Тип данных. 25

3.1.2. Домен. 25

3.1.3 Схема отношения, схема базы данных. 25

3.1.4 Кортеж, отношение, ключи. 25

3.1.5 Связи в реляционных базах данных. 27

3.2 Фундаментальные свойства отношений. 27

3.2.1 Отсутствие кортежей-дубликатов. 27

3.2.2 Отсутствие упорядоченности кортежей. 27

3.2.3 Отсутствие упорядоченности атрибутов. 28

3.2.4 Атомарность значений атрибутов. 28

3.3. Характеристика реляционной модели данных. 28

3.4 Трехзначная логика (3VL) 29

3.5 Реляционная алгебра. 30

3.6 Особенности операций реляционной алгебры.. 39

3.7 Реляционное исчисление. 40

3.7 Вопросы и упражнения для самоконтроля к главе 3. 42

Глава 4 Элементы языка SQL.. 42

4.1 История языка SQL.. 42

4.2 Структура языка SQL.. 44

4.3 Создание запроса с помощью оператора SELECT. 46

4.3.1 Создание простых запросов. 46

4.3.2. Агрегирование данных в запросах. 48

4.3.3 Формирование запросов на основе соединения таблиц. 50

4.3.4 Формирование структур вложенных запросов. 52

4.3.5 Объединение нескольких запросов в один. 54

4.3.6 Синтаксис оператора SELECT. 55

4.4 Операторы манипулирования данных. 56

4.4.1 Оператор удаления данных DELETE.. 56

4.4.2 Оператор вставки данных INSERT. 56

4.4.3 Оператор обновления данных UPDATE.. 57

4.5 Операторы определения объектов базы данных. 57

4.5.1 Операторы определения таблицы.. 57

4.5.2 Оператор определения представлений CREATE VIEW... 59

4.6 Операторы контроля данных, защиты и управления данными. 60

4.6.1 Операторы управления привилегиями. 60

4.6.2 Операторы управления транзакциями. 62

4.6.3 Проблемы параллельной работы транзакций. 64

4.7 Вопросы и упражнения для самоконтроля к главе 4. 65

Глава 5 Проектирование баз данных. 66

5.1 Проектирование реляционных БД с использованием принципов нормализации. 67

5.2 Проектирование реляционных БД с использованием семантических моделей. 72

5.2.1 Применение семантических моделей при проектировании. 72

5.2.2. Основные понятия модели Entity-Relationship. 74

5.2.3 Пример разработки простой ER-модели. 76

5.3 Практические рекомендации по проектированию БД.. 79

5.4 Вопросы и упражнения для самоконтроля к главе 5. 80

Глава 6 Функции СУБД и системы обработки транзакций. 81

6.1 Основные функции СУБД.. 81

6.2 Системы обработки транзакций. 84

6.2.1 OLTP-системы.. 84

6.2.2 OLAP -системы.. 84

6.2.3 Мониторы транзакций. 85

6.3 Архитектура СУБД.. 87

6.4 Вопросы и упражнения для самоконтроля по главе 6. 88

Глава 7 Технологии, модели и архитектура систем обработки данных. 88

7.2 Распределенная обработка данных. 92

7.2.1 Аспекты сетевого взаимодействия. 92

7.2.2 Технология распределенной БД (технология STAR) 96

7.2.3 Технология тиражирования данных. 97

7.3 Концепция активного сервера в модели DBS. 98

7.4 Вопросы и упражнения для самоконтроля к главе 7. 101

Литература. 101

Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

Традиционно фиксация данных осуществляется с помощью конкретного средства общения, например, с помощью естественного языка на конкретном носителе (например, бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение «Стоимость авиабилета 128». Здесь «128» – данное, а «Стоимость авиабилета» – его семантика.

Нередко данные и интерпретация разделены. Например, «Расписание движения самолетов» может быть представлено в виде таблицы (таблица 1.1), в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить сведения из нижней части таблицы).

Таблица 1.1 – Расписание движения самолетов

Интерпретация
Номер рейса	Дни недели	Пункт отправления	Время вылета	Пункт назначения	Время прибытия	Тип самолета	Стоимость билета
Данные
	2_4_7	Баку	21.12	Москва	0.52	ИЛ-86	115.00
	3_6	Ереван	7.20	Киев	9.25	ТУ-154	92.00
	2_6	Казань	22.40	Баку	23.50	ТУ-134	73.50
	1 по 7	Киев	14.10	Москва	16.15	ТУ-154	57.00
	2_3_5	Минск	10.50	Сочи	13.06	ИЛ-86	78.50
	1_3_6	Москва	15.17	Баку	18.44	ИЛ-86	115.00
	1 по 7	Москва	9.05	Киев	11.05	ТУ-154	57.00
	1_3_5	Рига	21.53	Таллин	22.57	АН-24	21.50
	3_6	Сочи	18.25	Баку	20.12	ТУ-134	44.00
	2_4_6	Таллин	6.30	Рига	7.37	АН-24	21.50

Применение ЭВМ для ведения (ведение данных – термин, объединяющий действия по добавлению, удалению или изменению хранимых данных) и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не «знает», является ли «21.50» стоимостью авиабилета или временем вылета).

Существуют по крайней мере две исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации:

1. ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке – основном языке интерпретации данных;

2. стоимость памяти ЭВМ была первоначально весьма велика.

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

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

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

В книге У. Девиса (Операционные системы, М., Мир, 1980) приведен пример:

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

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых «Системы управления базами данных» (СУБД). Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банками данных, а затем базами данных (БД).

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

СОЗДАТЬ ТАБЛИЦУ Расписание (Номер_рейса Целое Дни_недели Текст (8) Пункт_отправления Текст (24) Время_вылета Время Пункт_назначения Текст (24) Время_прибытия Время Тип_самолета Текст (8) Стоимость_билета Валюта);

и ввести его вместе с данными в БД «Аэропорт».

Язык запросов СУБД позволяет обращаться за выборкой данных как из программ, так и с терминалов). Сформировав запрос

ВЫБРАТЬ Номер_рейса, Дни_недели, Время_вылетаИЗ ТАБЛИЦЫ РасписаниеГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Киев' И Время_вылета > 17;

получим расписание «Москва-Киев» на вечернее время, а по запросу

ВЫБРАТЬ КОЛИЧЕСТВО(Номер_рейса)ИЗ ТАБЛИЦЫ РасписаниеГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Минск';

получим количество рейсов «Москва-Минск».

Эти запросы не потеряют актуальности и при расширении таблицы:

ДОБАВИТЬ В ТАБЛИЦУ Расписание Длительность_полета Целое;

как это было с программами обработки почтовых адресов при введении почтового индекса.

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