
- •Содержание
- •Глава 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
- •Литература
1.3 Терминология в субд
В общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике, изданных в 1982 г., приводятся следующие определения основных понятий:
База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области (ПО).
Предметная область (ПО) – часть реального мира, подлежащая автоматизации с целью организации управления. Она представлена множеством фрагментов, каждый из которых характеризуется объектами, процессами и множеством пользователей.
Банк данных (БнД) – это система специальным образом организованных данных – баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.
Системы управления базами данных (СУБД) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
Программы, с помощью которых пользователи работают с БД, называются приложениями.
СУБД должна обеспечивать:
возможность представления внутренней структуры данных;
физическую и логическую независимость данных;
минимальную избыточность данных;
возможность быстрого поиска;
эффективные языки запросов к данным;
требования безопасности, надежности, конфиденциальности, целостности:
данные должны быть защищены от искажения, хищения, разрушения;
данные должны быть восстанавливаемыми;
данные должны быть контролируемыми;
должна быть установлена процедура идентификации пользователей;
должна быть организована система санкционированного доступа;
должен быть установлен контроль за действиями пользователя с целью обнаружения ошибочных операций;
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
физическом размещении в памяти данных и их описаний;
механизмах поиска запрашиваемых данных;
проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
поддержании БД в актуальном состоянии и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных. Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь БД, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом БД, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 1.1).
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область. Остальные модели, показанные на рис. 1.1, являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической или концептуальной моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся «прозрачными» для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Рисунок. 1.1. Уровни моделей данных