- •Введение
- •Глава 1. Основные понятия баз данных
- •1.1. История возникновения баз данных
- •1.2. Модели данных
- •1.2.1. Иерархическая модель данных
- •1.2.2. Сетевая модель базы данных
- •1.2.3. Реляционная модель базы данных
- •1.2.4. Другие модели баз данных (ООСУБД)
- •2.1. История появления и развития SQL
- •Глава 2. SQL
- •2.2. Стандарты SQL
- •2.2.1. Стандарты ANSI/ISO
- •2.2.2. ODBC и консорциум SQL Access Group
- •2.2.3. JDBC и серверы приложений
- •2.3. SQL и переносимость
- •2.4. SQL и сети
- •2.4.1. Централизованная архитектура
- •2.4.2. Архитектура файлового сервера
- •2.4.3. Архитектура “клиент/сервер”
- •2.4.4. Многоуровневая архитектура
- •2.4.5. SQL и мэйнфреймы
- •2.4.7. SQL и UNIX
- •2.4.8. SQL и персональные компьютеры
- •2.4.9. SQL, хранилища данных и интеллектуальные ресурсы предприятия
- •2.4.10. SQL и интернет-приложения
- •2.5. Основы SQL
- •2.5.1. Использование SQL для извлечения информации из таблиц
- •2.5.2. Команда SELECT
- •2.5.3. Создание более сложных предикатов в предложении SELECT
- •2.5.4. Формирование вывода запросов
- •2.5.5. Агрегатные группы
- •2.6. Запросы к нескольким таблицам
- •2.6.1. Подзапросы
- •2.6.2. Использование операторов ANY, ALL и SOME
- •2.6.3. Использование предложения UNION
- •2.6.4. Ввод, удаление и изменение значения поля
- •2.7. DDL (Язык описания данных)
- •2.7.1. Создание таблиц
- •2.7.2. Индексы
- •2.7.3. Изменение структуры таблицы после ее создания
- •2.8. Ограничение данных
- •2.8.1. Ограничение таблиц
- •2.8.2. Установка значений по умолчанию
- •2.9. Поддержка целостности данных
- •2.9.1. Первичные ключи
- •2.9.2. Пользовательские представления
- •2.10. Модификация данных с помощью представлений
- •2.11. Разграничение доступа в базе данных
- •Глава 3. Математические основы реляционных баз данных
- •3.1. Отношения и их схемы
- •3.2. Реляционные операторы
- •3.2.1. Булевы операции
- •3.2.2. Оператор выбора
- •3.2.3. Оператор проекции
- •3.2.4. Оператор соединения
- •3.2.5. Другие операции на отношениях
- •3.2.6. Оператор деления
- •3.2.7. Оператор переименования атрибутов
- •3.2.8. Оператор эквисоединения
- •3.2.9. Расширения для сравнения на доменах
- •3.2.9.1. Расширение выбора
- •3.3. Реляционная алгебра
- •3.3.1. Дополнительные операторы
- •3.3.1.1. Оператор расщепления
- •3.3.1.2. Оператор FACTOR
- •3.4. Функциональные зависимости
- •3.4.1. Определение
- •3.4.2. Аксиомы вывода
- •3.4.3. Применение аксиом вывода
- •3.4.4. Выводы на основе аксиом вывода
- •3.4.6. Направленные ациклические графы вывода
- •3.4.7. Проверка принадлежности к замыканию множества функциональных зависимостей
- •3.5. Покрытия функциональных зависимостей
- •3.5.1. Покрытия и эквивалентность
- •3.5.2. Неизбыточные покрытия
- •3.5.3. Редуцированные покрытия
- •3.5.3.1. Посторонние атрибуты
- •3.5.3.3. Алгоритм построения редуцированного покрытия
- •3.5.3.4. Канонические покрытия
- •3.5.3.5. Структура неизбыточных покрытий
- •3.5.4. Минимальные покрытия
- •3.5.4.1. Прямая определяемость
- •3.5.4.2. Вычисление минимальных покрытий
- •3.5.4.3. Оптимальные покрытия
- •3.5.5. Составные функциональные зависимости
- •3.5.6. Кольцевые покрытия
- •3.6. Многозначные зависимости и зависимости соединения
- •3.6.1. Многозначные зависимости
- •3.6.2. Многозначные и функциональные зависимости
- •3.6.3. Аксиомы вывода для многозначных зависимостей
- •3.6.4. Только многозначные зависимости
- •3.6.5. Функциональные и многозначные зависимости
- •3.6.6. Зависимости соединения
- •3.7. Синтез схем реляционных баз данных
- •3.7.1. Базы данных и их схемы
- •3.7.2. Нормальные формы баз данных
- •3.7.2.1. Первая нормальная форма
- •3.7.2.2. Вторая нормальная форма
- •3.7.2.4. Нормальная форма Бойса - Кодда (НФБК)
- •3.7.2.5. Четвертая нормальная форма
- •3.7.2.3. Третья нормальная форма
- •3.8. Алгоритмы синтеза схем баз данных
- •3.8.1. Нормализация через декомпозицию
- •3.8.2. Недостатки нормализации через декомпозицию
- •3.8.3. Нормализация посредством синтеза
- •Глава 4. Система управления базами данных PostgreSQL
- •4.1. Установка
- •4.2. Запуск и останов сервера PostgreSQL
- •4.2.1. Утилита psql
- •4.2.2. Создание базы данных
- •4.3. Объекты базы данных
- •4.4. Функции и операторы
- •4.4.1. Логические операторы
- •4.4.2. Операторы сравнения
- •4.5. Клиентские приложения PostgreSQL
- •4.5.1. clusterdb
- •4.5.2. createdb
- •4.5.3. createuser
- •4.5.4. dropdb
- •4.5.5. dropuser
- •4.5.6. ecpg
- •4.5.7. pg_basebackup
- •4.5.8. pgbench
- •4.5.9. pg_config
- •4.5.10. pg_dump
- •4.5.11. pg_dumpall
- •4.5.12. pg_isready
- •4.5.13. pg_receivewal
- •4.5.14. pg_restore
- •4.5.15. psql
- •4.5.16. reindexdb
- •4.5.17. vacuumdb
- •4.6. Серверные приложения PostgreSQL
- •4.6.1. initdb
- •4.6.2. pg_archivecleanup
- •4.6.3. pg_checksums
- •4.6.4. pg_controldata
- •4.6.6. pg_resetwal
- •4.6.7. pg_rewind
- •4.6.8. pg_test_fsync
- •4.6.9. pg_test_timing
- •4.6.10. pg_upgrade
- •4.6.11. pg_waldump
- •4.6.12. postgres
- •4.6.13. postmaster
- •4.7. Серверное программирование
- •4.7.1. Расширение SQL
- •4.7.2. Триггеры
- •Заключение
- •Библиографический список
- 17 -
различались. Стандарт SQL-92 в некоторой степени унифицирует этот процесс, но не может полностью скрыть детали реализации.
2.4. SQL и сети
Резкий рост компьютерных сетей в 1990-х годах оказал большое влияние на управление базами данных и придал SQL новые возможности. По мере распространения сетей приложения, которые традиционно работали на центральном мини-компьютере или мэйнфрейме, переводятся на серверы и рабочие станции ЛВС. В таких сетях SQL играет важнейшую роль и связывает приложение, выполняющееся на рабочей станции с графическим пользовательским интерфейсом, и СУБД, управляющую совместно используемыми данными на сервере. Рост популярности Интернета и Веб еще больше усилил влияние SQL в сфере сетевых технологий. С появлением трехуровневой архитектуры Интернета язык SQL стал связующим звеном между прикладной логикой (работающей на среднем уровне, сервере приложений или веб-сервере) и базой данных (третий уровень).
2.4.1. Централизованная архитектура
В этой архитектуре и СУБД, и сами физические данные размещаются на центральном мини-компьютере или мэйнфрейме вместе с приложением, принимающим входную информацию с пользовательского терминала и отображающим на нем же данные. Прикладная программа "общается" с СУБД с помощью SQL.
Недостатки централизованной архитектуры проявляются при масштабировании. Поскольку система обслуживает много различных пользователей, каждый из них ощущает снижение быстродействия по мере увеличения нагрузки на систему.
2.4.2. Архитектура файлового сервера
Появление персональных компьютеров и локальных вычислительных сетей привело к разработке архитектуры файлового сервера. При такой архитектуре приложение, выполняемое на персональном компьютере, может получить прозрачный доступ к файловому серверу, на котором хранятся совместно используемые файлы. Когда приложение, работающее на персональном компьютере, запрашивает данные из такого файла, сетевое программное обеспечение автоматически считывает требуемый блок данных с сервера. Архитектура файловых серверов поддерживалась первыми СУБД для персональных компьютеров, такими как dBASE и позднее
- 18 -
Microsoft Access, при этом на каждом персональном компьютере работала своя копия СУБД.
При выполнении типичных запросов, когда требуется получение одной или небольшого количества строк из базы данных, эта архитектура обеспечивает великолепную производительность, поскольку в распоряжении каждой копии СУБД находятся все ресурсы персонального компьютера.
2.4.3. Архитектура “клиент/сервер”
Здесь персональные компьютеры объединены в локальную сеть, в которой имеется сервер баз данных, хранящий общие базы данных. Функции СУБД разделены на две части: пользовательские программы, такие как приложения для формирования интерактивных запросов, генераторы отчетов и прикладные программы, выполняются на клиентском компьютере, а ядро базы данных, которое хранит данные и управляет ими, работает на сервере. В этой архитектуре, популярность которой существенно возросла в течение 1990-х годов, SQL стал стандартным языком, обеспечивающим взаимодействие между пользовательскими программами и ядром базы данных.
При архитектуре "клиент/сервер" запрос передается по сети на сервер баз данных в виде SQL-запроса. Ядро базы данных на сервере обрабатывает запрос и просматривает базу данных, которая также расположена на сервере. После вычисления результата ядро базы данных посылает его обратно по сети клиентскому приложению, которое отображает его на экране персонального компьютера.
Архитектура "клиент/сервер" снижает сетевой трафик и распределяет процесс загрузки базы данных. Функции для работы с пользователем, такие как обработка ввода и отображение данных, выполняются на персональном компьютере пользователя. Функции для работы с данными, такие как дисковый ввод-вывод и выполнение запросов, выполняются сервером баз данных. Наиболее важно то, что SQL обеспечивает четко определенный интерфейс между клиентской и серверной системами, эффективно передавая запросы на доступ к базе данных.
Преимущества данной архитектуры сделали ее наиболее популярной схемой при разработке новых приложений в середине 1990-х годов. Все ведущие СУБД — Oracle, Informix, Sybase, SQL Server, DB2 и многие другие — стали предлагать клиент-серверные возможности. Многие компании начали выпускать средства разработки приложений "клиент/сервер". Некоторые из них разрабатывались производителями баз данных, иные — сторонними производителями.
-19 -
2.4.4.Многоуровневая архитектура
С развитием Интернета и особенно Веб архитектура сетевого управления базами данных получила дальнейшее развитие. Поначалу WWW являлась средой просмотра статических документов и развивалась независимо от рынка СУБД. Но когда веб-браузеры получили широкое распространение, разработчики пришли к выводу, что это очень удобный способ обеспечения доступа к корпоративным базам данных. Предположим, к примеру, что торговая компания располагает собственным веб-сайтом, на котором клиенты могут найти информацию о товарах, выпускаемых компанией, включая текстовое и графическое их описание. Естественным следующим шагом будет предоставление клиентам доступа к информации о наличии выбранного товара на складе, причем посредством того же интерфейса веб-браузера. Для этого требуется связать последний с базой данных, хранящей такую (постоянно меняющуюся) информацию.
Методы связывания веб-серверов и СУБД стремительно развивались в конце 1990-х - начале 2000-х годов, и в итоге это вылилось в трехуровневую сетевую архитектуру. Интерфейсом пользователя является веб-браузер, работающий на персональном компьютере или некотором другом "тонком клиенте", например таком, как смартфон. Браузер взаимодействует с веб-сервером на прикладном уровне. Если пользователь запрашивает нечто большее, чем просто статические веб-страницы, веб-сервер переадресует запрос серверу приложений, роль которого заключается в применении бизнес-логики, необходимой для обработки запроса. Зачастую запрос включает обращение к старой системе, работающей на мэйнфрейме, либо к корпоративной базе данных. Это серверный уровень модели.
2.4.5. SQL и мэйнфреймы
Хотя иерархическая база данных IMS от IBM все еще предлагается для мэйнфреймов IBM и работает со многими высокопроизводительными приложениями, ведущей базой данных для мэйнфреймов уже более чем два десятилетия является SQL-база данных DB2. IBM предлагает реализации DB2 для разных архитектур, но DB2 для мэйнфреймов можно рассматривать как "плавбазу для всей эскадры" баз данных IBM. Любые новые разработки баз данных для мэйнфреймов используют DB2, укрепляя доминирующую роль SQL в области обработки данных на мэйнфреймах.
-20 -
2.4.6.SQL и мини-компьютеры
Сегмент рынка реляционных СУБД для мини-компьютеров начал развиваться одним из первых. Первые продукты компаний Oracle и Ingres предназначались для мини-компьютеров VAX/VMS компании Digital. С тех пор обе СУБД были перенесены на множество других платформ. СУБД компании Sybase, появившаяся позднее и предназначавшаяся для оперативной обработки транзакций, работала на нескольких платформах, включая VAX.
Кроме того, на протяжении 1980-х годов поставщики миникомпьютеров разрабатывали собственные реляционные СУБД на основе SQL. Компания Digital на каждую систему VAX/VMS устанавливала собственную СУБД Rdb/VMS. Компания HewlettPackard поставляла Allbase — СУБД, поддерживающую как HPSQL (диалект SQL от компании Hewlett-Packard), так и нереляционный интерфейс. Компания Data General поменяла свои старые нереляционные базы данных на СУБД DG/SQL. К тому же многие из поставщиков мини-компьютеров перепродавали реляционные СУБД независимых поставщиков. Все это помогло языку SQL утвердиться в качестве важной технологии в системах среднего уровня.
С середины 1990-х годов SQL-продукты поставщиков миникомпьютеров, в основном, исчезли, уступив место мультиплатформенным разработкам компаний Oracle, Informix, Sybase и др. Oracle приобрела Rdb компании Digital; другие продукты постепенно оказались заброшены. Одновременно с этим угасло и влияние специализированных операционных систем для миникомпьютеров — всех их заменила операционная система UNIX. Вчерашний рынок реляционных продуктов для мини-компьютеров стал сегодняшним рынком серверов баз данных для платформы UNIX.
2.4.7. SQL и UNIX
SQL был однозначно признан лучшим решением в области управления данными для компьютерных систем на базе платформы UNIX. Операционная система UNIX, которая изначально была разработана в Bell Laboratories, в 1980-х годах стала стремительно завоевывать популярность как независимая от производителя стандартная операционная система. Она работает на разнообразных компьютерных системах, начиная от рабочих станций и заканчивая мэйнфреймами, и стала стандартной операционной системой для высококачественных серверных систем, включая серверы баз данных.
В начале 1980-х годов были доступны четыре большие СУБД для UNIX-систем. Две из них, производства компаний Oracle и Ingres, были
