- •Глава 1. Базы данных и системы управления 9
 - •Глава 2. Организация доступа к данным 45
 - •Глава 3. Реляционная алгебра 60
 - •Глава 4. Основы sql 67
 - •Глава 5. Проектирование реляционных баз данных 89
 - •Глава 6. Взаимодействие sql с приложениями 116
 - •Глава 7. Некоторые проблемы администрирования баз данных 154
 - •Базы данных и системы управления
 - •Файловые системы
 - •Концепция баз данных
 - •Основные функции субд
 - •Непосредственное управление данными во внешней памяти
 - •Управление буферами оперативной памяти
 - •Управление транзакциями
 - •Журнализация
 - •Поддержка языков баз данных
 - •Трехуровневая модель архитектуры систем баз данных
 - •Модели данных
 - •Характеристика связей
 - •Компьютерно-ориентированные модели данных
 - •Реляционный подход
 - •Ключи и целостность реляционных данных
 - •Моделирование концептуальной схемы базы данных
 - •Организация доступа к данным
 - •Страницы и файлы
 - •Индексирование
 - •Структуры типа б-дерева
 - •Хеширование
 - •Методы сжатия
 - •Метод дифференциального сжатия
 - •Иерархические методы сжатия
 - •Кодирование по методу Хаффмена
 - •Реляционная алгебра
 - •Традиционные реляционные операции
 - •Специальные реляционные операции
 - •Дополнительные реляционные операции
 - •Примеры использования реляционной алгебры для выражения словесных запросов в виде формул
 - •Основы sql
 - •Типы данных
 - •Строковые типы данных
 - •Битовые типы данных
 - •Точные числовые типы данных
 - •Вещественные числовые типы данных
 - •Календарные типы данных
 - •Значения null
 - •Создание и обслуживание таблиц
 - •Запрос на выборку
 - •Статистические функции
 - •Создание соединений
 - •Вложенные запросы
 - •Запрос на объединение
 - •Запросы, выполняющие реляционные операции вычитания, пересечения и деления
 - •Запросы на изменение
 - •Перекрестные запросы
 - •Проектирование реляционных баз данных
 - •Нормализация отношений
 - •Функциональные зависимости
 - •Н ормальные формы, обоснованные функциональными зависимостями
 - •Нормальная форма Бойса–Кодда
 - •Нормальные формы, обоснованные более сложными зависимостями
 - •Процедура нормализации и проектирования
 - •Пример проектирования базы данных
 - •Назначение и предметная область
 - •Проектирование базы данных
 - •Взаимодействие sql с приложениями
 - •Встраивание sql-операторов в программный код
 - •Тип курсора
 - •Триггеры
 - •Хранимые процедуры
 - •Стандартные интерфейсы для доступа к данным
 - •Информационное окружение веб-сервера
 - •Стандарт odbc
 - •Уровни соответствия
 - •Уровень соответствия odbc
 - •Задание имени источника данных odbc
 - •Расширяемый язык разметки xml
 - •Xml как язык разметки
 - •Материализация хмl-документов с помощью xslt
 - •Создание хмl-документов на основе информации из базы данных
 - •Некоторые проблемы администрирования баз данных
 - •Оптимизация запросов
 - •Параллельная обработка данных
 - •Потеря обновления
 - •Зависимость от незафиксированных обновлений
 - •Несогласованный анализ
 - •Блокировки транзакций
 - •Согласованность и уровень изоляции транзакций
 - •Распределенные системы баз данных
 - •Фрагментация
 - •Репликация
 - •Распространение обновлений
 - •Управление каталогом
 - •Распределенная обработка запросов
 - •Типы распределенных систем баз данных
 - •Нераспределенные мультибазовые субд
 - •Клиент-серверные системы
 - •Системы с общими ресурсами
 - •Технические аспекты администрирования базы данных
 - •Восстановление базы данных
 - •Безопасность баз данных
 - •Шифрование данных
 - •Производительность баз данных
 - •Администрирование данных
 - •Литература
 
Стандартные интерфейсы для доступа к данным
Рассмотрим стандартные интерфейсы для доступа к серверам баз данных. ODBC (Open Database Connectivity standard – открытый стандарт взаимодействия с базой данных) был разработан в начале 1990-х годов компанией X/Open с целью обеспечить независимый от СУБД способ обработки информации из реляционных баз данных. В середине 1990-х годов компания Microsoft представила OLE DB – объектно-ориентированный интерфейс, имеющий функциональность сервера данных. OLE DB был разработан не только для реляционных баз данных, но и для многих других типов источников данных. Будучи СОМ-интерфейсом, OLE DB непосредственно доступен из С++, С# и Java, но недоступен из Visual Basic и сценарных языков. Поэтому компания Microsoft разработала ADO (Active Data Objects) – набор объектов, позволяющий использовать OLE DB из любых языков программирования, включая Visual Basic, VBScript и JScript.
Прежде чем рассматривать эти стандарты, составим сначала представление о том, какое окружение имеет веб-сервер в приложениях баз данных, использующих Интернет-технологии.
Информационное окружение веб-сервера
Окружение, в котором находятся современные приложения баз данных, использующие Интернет-технологии, весьма многообразно и сложно по составу. Как показывает рис. 6.5.1, типичный веб-сервер должен публиковать приложения, содержащие данные из множества различных источников. Пока что мы рассматривали только реляционные базы данных, однако существуют и другие типы источников данных. Рассмотрим, с какими проблемами сталкивается разработчик серверных приложений при интеграции данных из различных источников. В качестве таких источников могут выступать база данных Oracle, база данных DB2 для больших ЭВМ, иерархическая база данных IMS, системы обработки файлов VSAM и ISAM, папки электронной почты и т.д. Каждый из этих продуктов имеет свой собственный программный интерфейс, который разработчик должен выучить. Кроме того, каждый из этих продуктов меняется, и со временем будут добавлены новые возможности и функции, что еще больше усложнит задачу разработчика.
Рис.6.5.1. Многообразие типов данных
Стандарт odbc
Стандарт ODBC был разработан для решения проблемы, которая относится к реляционным базам данных и источникам данных, имеющим табличную организацию, например электронным таблицам. Как показано на рис. 6.5.2, ODBC является интерфейсом между веб-сервером (или другим пользователем базы данных) и сервером базы данных. Он представляет собой набор стандартов, позволяющих, кроме прочего, запускать на выполнение SQL-операторы и возвращать результаты и сообщения об ошибках. Из рисунка понятно, что разработчики могут обращаться к серверам данных через «родные» интерфейсы, если таковы их предпочтения (иногда это делается для увеличения производительности), но когда работы слишком много, а время и желание изучать множество библиотек собственных интерфейсов СУБД отсутствуют, то вместо этих библиотек можно пользоваться ODBC.
Рис. 6.5.2. Назначение стандарта ODBC
Стандарт ODBC – это интерфейс, с помощью которого прикладные программы могут обращаться к SQL-базам данных и обрабатывать их независимым от СУБД способом. Это означает, к примеру, что приложение, которое использует интерфейс ODBC, может обрабатывать базу данных Oracle, DB2, электронную таблицу и любую другую базу данных, совместимую с ODBC, без каких-либо изменений в программном коде. Цель состоит в том, чтобы дать разработчику возможность создать одно приложение, способное обращаться к базам данных, поддерживаемым различными СУБД, без необходимости его менять или даже перекомпилировать.
На рис. 6.5.3 показаны компоненты стандарта ODBC. Прикладная программа, диспетчер драйвера и драйверы СУБД находятся на сервере приложений. Диспетчеры посылают запросы источникам данных, которые находятся на сервере базы данных. Согласно стандарту, источник данных (data source) – это база данных, поддерживающая ее СУБД, операционная система и сетевая платформа. Источник данных ODBC может быть реляционной базой данных, файловым сервером и даже электронной таблицей.
Рис. 6.5.3. Архитектура ODBC. Приложение может обрабатывать базу данных с помощью любой из СУБД.
Приложение инициирует запросы на создание соединения с источником данных, на выполнение SQL-операторов и получение результатов, на обработку ошибок и на начало, фиксацию и откат транзакций. ODBC предоставляет стандартный способ для выполнения каждого из этих запросов и определяет стандартный набор кодов ошибок и сообщений.
Диспетчер драйвера (driver manager) служит в качестве посредника между приложениями и драйверами СУБД. Когда приложение запрашивает соединение, драйвер определяет тип СУБД, которая обрабатывает заданный источник данных ODBC, и загружает этот драйвер в память (если он еще не загружен). Диспетчер драйвера также обрабатывает определенные запросы на инициализацию и проверяет допустимость формата и порядка запросов к ODBC, которые он получает от приложения. В Windows диспетчер драйвера входит в состав операционной системы.
Драйвер (driver) обрабатывает запросы к ODBC и передает конкретные SQL-операторы на выполнение заданному источнику данных. Для каждого типа источника данных имеется свой драйвер. Например, есть драйверы для DB2, Oracle, Access и всех других продуктов, производители которых решили поддерживать стандарт ODBC. Драйверы поставляются производителями СУБД и независимыми компаниями.
Драйвер отвечает за то, чтобы стандартные команды ODBC выполнялись корректно. В некоторых случаях, если сам источник данных не соответствует стандарту SQL, драйверу приходится выполнять значительную работу, чтобы восполнить недостаток функциональности источника данных. В других случаях, когда источник данных имеет полномасштабную поддержку SQL, драйвер только передает запрос на обработку источнику данных. Драйвер также преобразует коды ошибок источника данных и сообщения в стандартные коды и сообщения ODBC.
ODBC определяет два типа драйверов: одноуровневые и многоуровневые. Одноуровневый драйвер (single-tier driver) занимается как обработкой вызовов ODBC, так и выполнением SQL-операторов. Пример одноуровневого драйвера изображен на рис. 6.5.4. В этом примере данные хранятся в файлах Xbase (это формат, используемый FoxPro, dBase и другими продуктами). Поскольку диспетчеры файлов Xbase не поддерживают SQL, преобразование SQL-запроса в команды манипуляции файлами Xbase и обратное преобразование результатов в SQL возлагаются на драйвер.
Рис. 6.5.4. Одноуровневый драйвер ODBC
Многоуровневый драйвер (multi-tier driver) занимается только обработкой вызовов ODBC, а SQL-запросы передает на выполнение серверу базы данных. Он может переформатировать SQL-запрос, чтобы тот соответствовал диалекту источника данных, но выполнение запроса не входит в его функции. Пример использования многоуровневого драйвера показан на рис. 6.5.5.
Рис. 6.5.5. Многоуровневый драйвер ODBC
