Глушаков С.В., Ломотько Д.В. Базы данных

Подождите немного. Документ загружается.

100

Часть!, Теория баз данных

простое натуральное число Значения,

содержащегося в хеш-поле

Из этого ясно, что хеширование отличается от индексирова-

ния тем, что в файле может быть любое количество индексов, но

только одно хеш-поле. Теоретически можно было бы для опреде-

ления адреса вместо функции использовать непосредственно зна-

чение ключевого числового поля, однако практически такой спо-

соб непригоден, т. к. диапазон возможных значений ключевого

поля может быть гораздо шире диапазона имеющихся адресов.

Таким образом, во избежание неэффективного использования

дискового пространства следует найти такую хеш-функцию, что-

бы можно было сузить диапазон до оптимальной величины с уче-

том возможности резервирования дополнительного пространства.

Недостаток хеширования заключается в том, что физическая

последовательность записей внутри хранимого файла почти все-

гда отличается от последовательности ключевого поля, а также

любой другой логически заданной последовательности, а между

последовательно размещенными записями могут быть промежут-

ки неопределенной протяженности. Практически всегда физиче-

ская последовательность записей в хранимом хешированием

файле принципиально иная по сравнению с заданной в нем логи-

ческой последовательностью.

Другим недостатком хеширования является возможность воз-

никновения ситуаций, когда две или более различных записей

имеют одинаковые адреса, поэтому иногда возникает необходи-

мость функцию исправлять. Если на одной странице располагает-

ся несколько записей, то для исправления можно воспользоваться

методом прямого перебора. Суть метода заключается в следую-

щем: предположим, что на пустой странице s размещается п за-

писей. Тогда, при размещении записей и возникновении первых п

совпадений по некоторому хеш-адресу s, все такие записи будут

размещены на этой странице и найдены при необходимости с

помощью прямого перебора. Однако при размещении следующей

п+1 записи и возникновении очередного совпадения, запись при-

дется разместить на дополнительной странице переполнения, для

чего понадобится дополнительная дисковая операция ввода-

вывода.

Необходимо иметь в виду, что с увеличением размера храни-

мого файла количество совпадений адресов увеличивается, что

приводит к значительному увеличению среднего времени досту-

па - ведь все больше времени придется тратить на поиск инфор-

мации в наборах конфликтующих записей. Это можно устранить,

Глава 1.6. Технология физического хранения и доступа к данным 101

если реорганизовать файл, т.е. загрузить данный файл, используя

новую хеш-функцию, что решается при помощи расширяемого

хеширования.

При использовании расширяемого хеширования необходимо,

чтобы все значения хеш-поля были уникальны, а это может быть

реализовано только в том случае, если хеш-поле является ключе-

вым. Основные принципы работы метода расширяемого хеширо-

вания следующие:

• если в качестве хеш-функции используется функция ф, а

значение ключевого поля для некоторой записи z равно р,

то в качестве результата хеширования значения ключево-

го поля будет получено значение псевдоключа для записи

z в виде <р(р). Здесь псевдоключ используется не в качест-

ве адреса записи, а лишь как косвенный указатель на ме-

сто их хранения;

• хранимый файл имеет связанный с ним каталог, который

также сохраняется на диске. Он состоит из заголовка, со-

держащего значение g, которое называется глубиной ка-

талога, а также 2

указателей на страницы с несколькими

записями данных на каждой.

Таким образом, с помощью каталога глубиной g можно орга-

низовать доступ к файлу, содержащему 2

различных страниц с

данными.

Если рассматривать первые g бит псевдоключа как целое без-

знаковое двоичное число Ь, то i-й указатель в каталоге будет от-

носиться к странице, содержащей все записи, для которых вели-

чина b равна i-1. Для того чтобы найти запись со значением клю-

чевого поля, равным р, следует с помощью хеш-функции вычис-

лить значение псевдоключа, а затем по первым g бит псевдоклю-

ча определить численное значение i-1 и найти в каталоге соответ-

ствующий ему i-й указатель на страницу, содержащую искомую

запись, что реализуется за два доступа к диску.

Здесь был описан лишь один из вариантов хеширования, од-

нако существует множество других способов реализации этой

основной идеи.

Для выполнения запросов можно применять другой, не ме-

нее эффективный, способ хранения данных с использованием

цепочек указателей. При этом, в отличие от индексирования,

оба файла могут находиться в одном наборе файлов, причем

файл, аналогичный индексному, в данном случае принято на-

зывать родительским, а файл с основными данными соответст-

венно дочерним.

102

Часть I. Теория баз данных

Рассмотрим такую структуру (ее часто называют родительско-

дочерней) на примере уже рассмотренного выше файла, содер-

жащего данные об успеваемости студентов. Тогда структура бу-

дет состоять из файлов успеваемости и учебных предметов, при

этом родительский файл будет содержать одну хранимую запись

для каждого предмета, предоставляя при необходимости назва-

ние предмета в качестве заголовка цепочки или кольца указате-

лей, связывающих вместе все дочерние записи об успеваемости

студентов по этому предмету (см. рис. 1.34).

Стоит обратить внимание на то, что поле с названиями пред-

метов PN отсутствует в файле успеваемости, т. к. СУБД для по-

иска студентов в зависимости от сданного предмета будет искать

строку с названием предмета в родительском файле, а затем из-

влекается вся связанная с данной строкой цепочка указателей.

Алгебра

Физика

Химия

USP (данные)

3412

3413

3414

3415

NAME

Поляков

Старова

Гриценко

Котенко

OCENKA

Рис. 1.34. Родительско-дочерняя структура для файла

с данными об успеваемости

Основным преимуществом родительско-дочерней структуры

является значительно более простое выполнение операций встав-

ки или удаления записей по сравнению с индексной структурой.

Кроме того, родительско-дочерняя структура занимает меньше

места на диске, чем соответствующая индексная структура, по-

скольку в ней не повторяется информация в родительском файле.

Однако такая структура имеет и некоторые недостатки. Напри-

мер, для данного предмета единственным путем доступа к п-му

студенту является цепочка с последовательным перебором всех

предыдущих записей студентов, а если для этих записей не вы-

полнена кластеризация, то для каждого доступа к данным может

потребоваться отдельная операция поиска и время доступа к за-

писи может оказаться очень большим.

С другой стороны, такая структура может быть оптимальной

для выполнения запроса на поиск студентов, сдавших тот или

Глава 1.6. Технология физического хранения и доступа к данным 103

иной предмет, однако она неэффективна для обратного запроса

на поиск предмета, сданного студентом, поэтому для обратного

запроса больше подошла бы индексная или хешированная струк-

тура. И. наконец, если родительский файл имеет очень большой

размер, то для него также потребуется применить индексирова-

ние или хеширование, а значит, цепочки указателей не являются

способом создания качественной структуры хранения данных и с

ними требуется совместно использовать другие методы.

Усовершенствование родительско-дочерней структуры можно

произвести за счет добавления в дочерних записях еще одного

указателя на соответствующую родительскую запись - при такой

организации цепочек можно было бы избежать просмотра всей

цепочки при выполнении запросов.

Сжатие данных

С целью сокращения пространства, необходимого для хра-

нения некоторого набора данных, часто используют технологии

сжатия. При этом в результате экономится не только простран-

ство на диске, но и количество дисковых операций ввода-

вывода, т. к. доступ к данным меньшего размера требует мень-

ше дисковых операций ввода-вывода. С другой стороны, для

распаковки и извлечения сжатых данных требуются некоторые

дополнительные манипуляции, но в целом преимущества со-

кращения операций ввода-вывода могут компенсировать недос-

татки, связанные с дополнительной обработкой данных.

Технологии сжатия основаны на малой вероятности того, что

данные имеют совершенно беспорядочную структуру. Наиболее

распространенной является технология сжатия на основе разли-

чий, при которой некоторое значение заменяется сведениями о

его отличиях от предыдущего значения. Следует отметить, что

для реализации такой технологии требуется размещать данные

последовательно, поскольку для их распаковки необходимо

иметь значение предыдущей величины. Такое сжатие весьма эф-

фективно для данных, к которым необходим последовательный

доступ, например для записей в одноуровневом списке. Более

того, в таких случаях наряду с данными допускается также сжать

и указатели. Дело в том, что если логическая последовательность

в файле соответствует физической последовательности размеще-

ния данных на диске, то соседние указатели будут незначительно

отличаться друг от друга, а значит, сжатие указателей может ока-

заться весьма полезным и эффективным.

104

Часть I. Теория баз данных

В качестве примера рассмотрим несколько записей со сле-

дующими данными:

Студент

Студентка

Студенческий

Предположим, что длина поля составляет 15 символов и спра-

ва от данных в несжатом виде содержится соответствующее ко-

личество пробелов. Один из способов применения сжатия на ос-

нове различий - это удаление повторяющихся символов в начале

каждой записи с указанием их количества, т. е. переднее сжатие.

В результате будет получено (числа соответствуют количеству

повторяющихся символов в начале имени, пробелы справа до

полной длины поля -15 символов - не показаны):

0 - Студент

7 - ка

6 - ческий

При необходимости можно осуществить дополнительное сжа-

тие, удаляя пробелы с указанием их количества, т. е. выполнить

так называемое заднее сжатие. Иногда еще допускается удаление

с правого конца каждого значения всех повторяющихся символов

в двух ближайших соседних значениях.

Другим способом уменьшения объема занимаемого данными

места является иерархическое сжатие. Предположим, что в хра-

нимом файле задана некоторая физическая последовательность

согласно выбранному полю, различные значения которого распо-

лагаются в нескольких последовательных записях этого файла.

Например, в хранимом файле успеваемости благодаря класте-

ризации, выполненной согласно полю PN с названиями предме-

тов, отдельно содержатся все записи о студентах, сдавших тот

или иной предмет. В таком случае набор всех записей с данными

о студентах, сдавших тот или иной предмет, может быть успешно

сжат в одну хранимую иерархическую запись, при этом название

предмета будет упомянуто только один раз, а вслед за ним будут

расположены данные о студентах (см. рис. 1.33).

Хранимая иерархическая запись состоит из двух частей: по-

стоянной, в нашем примере это поля с названиями предметов, и

переменной - записи с информацией о студентах. Такой набор

значений переменного количества внутри одной записи обычно

называется группой повторения. Таким образом, можно сказать.

Глава 1.6. Технология физического хранения и доступа к данным 105

что иерархическая запись, представленная на рис. 1.35, состоит

из значения поля предметов, и группы повторения с информаци-

ей о студентах, состоящей из полей с номерами студенческих

билетов, фамилий студентов и оценок по предмету.

Алгебра

USP

3415

(данные)

NAME

Котенко

OCENKA

Физика

Химия

3412

3414

3413

Поляков

Гриценко

Старова

Рис. 1.35. Внутрифайловое иерархическое сжатие файла

с данными об успеваемости

Иерархическое сжатие такого типа применяют и для индекса,

в котором несколько последовательно расположенных значений

содержат одни и те же повторяющиеся значения данных, но раз-

личные значения указателей.

Аяатапганьш образом можно применять иерархическое сжа-

тие на основе межфайловой кластеризации. Например, записи с

данными о студентах как бы объединяются с данными о всех

оценках по всем предметам для данного студента.

В заключение отметим, что структуру на основе цепочки ука-

зателей, вообще говоря, можно рассматривать как межфайловое

сжатие, которое не требует межфайловой кластеризации, т. к.

указатели позволяют логически достичь эффекта кластеризации.

Кодирование Хафмана - это еще одна технология кодиро-

вания символов, которая может быть весьма эффективной для

сжатия различных символов, встречающихся с разной часто-

той. Основная идея этого метода заключаете» в кодировании

отдельных символов битовыми строками различной длины,

причем наиболее часто встречающиеся символы кодируются

строками наименьшей длины. Кроме того, код любого символа

длиной п не должен совпадать с первыми п символами кода

какого-либо другого символа.

106

Часть I. Теория баз данных

Предположим, что некоторые данные записаны с помощью

символов А, Б, В. Г, Д, тогда с учетом относительной частоты, с

которой они встречаются, их коды приведены в таблице.

Таблица 1.4

Коды символов

Символ

Частота, %

Код

001

0001

0000

Символ А встречается чаще остальных, и потому имеет самый

короткий код. состоящий из одного бита. Все остальные коды

должны быть длиннее, однако нельзя использовать код на основе

одного нуля, так как он будет совпадать с начальной частью дру-

гих, более длинных кодов. Оценочно можно сказать, что в сред-

нем общая длина закодированного текста на 40% меньше, чем

при отсутствии кодирования.

Таким образом, рассмотрены важнейшие современные струк-

туры хранения данных, описана общая схема функционирования

программного обеспечения, предназначенного для доступа к дан-

ным, а также распределение выполнения этих задач между

СУБД, диспетчером файлов и диспетчером дисков. Основной

целью изложения было разъяснение общих идей и принципов без

описания отдельных подробностей их реализации в разных прак-

тически используемых системах и структурах хранения.

107

ЧАСТЬ II

СТРУКТУРИРОВАННЫЙ ЯЗЫК

ЗАПРОСОВ SQL

Глава 2.1

Введение в SQL

С чего начать?

Рост количества данных, необходимость их хранить и обраба-

тывать привели к тому, что возникла потребность в создании

стандартного языка БД, который мог бы функционировать в

большом количестве различных видов компьютерных систем.

Действительно, такой стандартный язык позволяет пользователям

манипулировать данными независимо от того, работают ли они

на персональном компьютере, сетевой рабочей станции, или на

универсальной ЭВМ.

SQL (Structured Query Language) - это сокращенное название

структурированного языка запросов, предоставляющего средства

создания и обработки данных в реляционных БД. Независимость

от специфики компьютерных технологий, а также поддержка

SQL лидерами промышленности в области технологии реляцион-

ных баз данных сделали его основным стандартным языком БД.

Все языки манипулирования данными, созданные до появле-

ния реляционных БД, разработанные для многих СУБД, были

ориентированы на операции с данными, представленными в виде

логических записей файлов. Разумеется, это требовало от пользо-

вателя детального знания организации хранения данных и серь-

езных усилий для указания того, какие данные необходимы, где

они размещаются и как их получить.

108

Часть II. Структурированный язык запросов SQL

Рассматриваемый язык SQL ориентирован на операции с дан-

ными, представленными в виде логически взаимосвязанных со-

вокупностей таблиц-отношений. Важнейшая особенность струк-

тур этого языка состоит в ориентации на конечный результат об-

работки данных, а не на процедуру этой обработки. SQL сам оп-

ределяет, где находятся данные, индексы и даже какие наиболее

эффективные последовательности операций следует использо-

вать для получения результата, поэтому не надо указывать эти

детали в запросе к БД.

Появление теории реляционных БД дало толчок к разработке

ряда языков запросов, которые можно отнести к двум классам:

• алгебраические языки, позволяющие выражать запросы

средствами специализированных операторов, применяе-

мых к отношениям;

• языки исчисления предикатов, представляющие собой

набор правил для записи выражения, определяющего но-

вое отношение из заданной совокупности существующих

отношений. Следовательно, исчисление предикатов есть

метод определения того отношения, которое желательно

получить, как ответ на запрос из отношений, уже имею-

щихся в БД.

В 1987 году SQL стал стандартом языков для профессиональных

реляционных СУБД и начал внедряться во все распространенные

системы. Это связано с рядом следующих моментов. Посгаяшый

рост быстродействия, а также снижение энергопотребления, разме-

ров и стоимости компьютеров привели к резкому расширению воз-

можных рынков их сбыта, круга пользователей, разнообразия типов

и цен. Естественно, что расширился спрос на разнообразное про-

граммное обеспечение. В борьбе за покупателя фирмы, производя-

щие программное обеспечение, стали выпускать на рынок все более

интеллектуальные, а значит, объемные программные комплексы.

Приобретая их, многие организации и отдельные пользователи часто

не могли разместить их на собственных ЭВМ. Для обмена информа-

цией и ее распространения были созданы сети ЭВМ, где обобщаю-

щие программы и данные стали размещать на специальных файло-

вых серверах.

СУБД,- работающие с файловыми серверами, позволяют мно-

жеству пользователей разных ЭВМ, расположенных достаточно

далеко друг от друга, получать доступ к одним и тем же БД. При

этом упрощается разработка различных автоматизированных сис-

Гпава 2.1. Введение в SQL

109

тем управления организациями, учебных комплексов, информаци-

онных и других систем, где множество сотрудников или учащихся

должны использовать общие данные и обмениваться создаваемой в

процессе работы информацией. Однако при таком подходе вся об-

работка запросов из программ или с терминалов пользовательских

ЭВМ на них и выполняется, поэтому для реализации даже просто-

го запроса необходимо считывать из файлового сервера или запи-

сывать на сервер целые файлы, а это ведет к конфликтным ситуа-

циям и перегрузке сети. Для исключения указанных недостатков

была предложена технология клиент/сервер, однако при этом ну-

жен единый язык общения с сервером - и в его качестве был вы-

бран SQL.

Реализация в SQL концепции операций, ориентированных на

табличное представление данных, позволила создать компактный

язык с небольшим набором предложений. SQL может использо-

ваться как для выполнения запросов, так и для построения при-

кладных программ. В нем существуют:

• предложения определения- данных - определение БД, а

также определение и уничтожение таблиц и индексов;

• запросы на выбор данных - предложение SELECT;

• предложения модификации данных - добавление, удале-

ние и изменение данных;

• предложения управления данными - предоставление и

отмена привилегий на доступ к данным, управление тран-

закциями и другие.

Кроме того, SQL предоставляет возможность выполнять в

этих предложениях:

• арифметические вычисления, включая разнообразные

функциональные преобразования, обработку текстовых

строк и выполнение операций сравнения значений ариф-

метических выражений и текстов;

• упорядочение строк или столбцов при выводе содержи-

мого таблиц на печать или экран дисплея;

• создание представлений, позволяющих пользователям ин-

терпретировать данные без увеличения их объема в БД;

• сохранение выводимого по запросу содержимого таб-

лицы, нескольких таблиц или представления в другой

таблице;

• группирование данных и применение к этим группам та-

ких операций, как среднее, сумма, максимум, минимум,

число элементов и т.п.

110

Часть II. Структурированный язык запросов SQL

Стандарт SQL определяется ANSI (американским национальным

институтом стандартов) и в данное время также принимается ISO

(международной организацией по стандартизации). Однако боль-

шинство коммерческих программ БД расширяют SQL без уведом-

ления ANSI, добавляя различные другие особенности в этот язык,

которые, как они считают, будут весьма полезны. Иногда это не-

сколько нарушает стандарт языка, хотя хорошие идеи имеют тен-

денцию развиваться и вскоре становятся стандартами.

Язык SQL является основой многих СУБД, т.к. он отвечает

за физическое структурирование и запись данных на диск, а

также за физическое чтение данных с диска и позволяет при-

нимать SQL-запросы от других компонентов СУБД и пользо-

вательских приложений. Таким образом, SQL является мощ-

ным инструментом, который обеспечивает пользователям,

программам и вычислительным системам доступ к информа-

ции, содержащейся в реляционных БД.

Основные достоинства языка SQL заключается в следующем:

• стандартность языка SQL - как уже было сказано, его ис-

пользование в программах стандартизировано международ-

ными организациями;

• независимость от конкретных СУБД - все распространенные

СУБД используют SQL, т.к. реляционную БД и программы,

которые с ней работают, можно перенести с одной СУБД на

другую с минимальными доработками;

• возможность переноса с одной вычислительной системы на

другую - СУБД может быть ориентирована на различные

вычислительные системы, однако приложения, созданные с

помощью SQL, допускают использование как для локаль-

ных БД так и для крупных многопользовательских систем;

• реляционная основа языка - SQL является языком реляци-

онных БД поэтому он стал популярным тогда, когда попу-

лярной стала реляционная модель представления данных.

Табличная структура реляционной БД хорошо понятна, по-

этому язык SQL является простым и легким для изучения;

• возможность создания интерактивных запросов - SQL обес-

печивает пользователям немедленный доступ к данным, при

этом в интерактивном режиме можно получить результат

запроса за очень короткое время без написания сложной

программы;

Глава 2.1. Введение в SQL

111

• возможность программного доступа к БД - язык SQL

может быть легко использован в приложениях, кото-

рым необходимо обращаться к БД. Одни и те же опера-

торы SQL используются как для интерактивного, так и

для программного доступа, поэтому части программ,

содержащие обращения к БД, можно вначале прове-

рить в интерактивном режиме, а затем встраивать в

программу;

• обеспечение различного представления данных - с помо-

щью SQL можно предусмотреть такую структуру данных,

что тот или иной пользователь будет видеть различные

представления данных. Кроме того, данные из разных

частей БД могут быть скомбинированы и представлены

пользователю в виде одной простой таблицы, а значит,

представления можно использовать для усиления защиты

БД и ее настройки под конкретные требования отдельных

пользователей;

• возможность динамического изменения и расширения

структуры БД - язык SQL даже во время обращения к со-

держимому позволяет манипулировать структурой БД.

Это большое преимущество перед языками статического

определения данных, которые запрещают доступ к БД во

время изменения ее структуры. Таким образом, SQL

обеспечивает гибкость с точки зрения приспособленности

БД к изменяющимся требованиям предметной области,

не прерывая при этом работу приложения, выполняющую

в реальном масштабе времени;

• поддержка архитектуры клиент/сервер - SQL одно из

лучших средств для реализации приложений на платфор-

ме клиент/сервер. При этом SQL служит связующим зве-

ном между клиентской системой, взаимодействующей с

пользователем, и серверной системой, управляющей БД,

позволяя каждой из них сосредоточиться на выполнении

своих прямых функций.

История развития SQL

Системы управления реляционными БД свою особую попу-

лярность приобрели в конце 80-х годов. Т.к. информация в таких

БД хранится в простой табличной форме, это дает много пре-

имуществ по сравнению с другими моделями представления дан-

112

Часть II. Структурированный язык запросов SQL

Глава 2.1. Введение в SQL

113

ных. Поскольку SQL является языком реляционных БД, то его

история тесно связана с развитием этого способа представления

информации.

Как уже было сказано, понятие реляционной БД введено в на-

чале 70-х годов Э. Ф. Коддом, научным сотрудником компании

IBM. После этого начались исследования в области реляционных

баз данных, включая большой исследовательский проект компа-

нии ТВМ, названный System/R, в котором проверялась и доказы-

валась работоспособность реляционной модели. Кроме разработ-

ки самой СУБД, в рамках проекта проводилась работа над созда-

нием языков запросов к БД, один из которых был назван

SEQUEL (Structured English Query Language - структурированный

английский язык запросов).

В конце 70-х годов осуществлена вторая реализация проекта

System/R, в результате чего система была установлена на компь-

ютерах нескольких заказчиков компании ШМ для опытной экс-

плуатации. Это принесло первый реальный опыт работы с СУБД

System/R и ее языком БД, который позже был переименован в

SQL. В результате ШМ сделала заключение, что реляционные БД

вполне работоспособны и могут служить основой для создания

программных продуктов.

Проект System/R и созданный в его рамках язык работы с

БД привлекли пристальное внимание специалистов во всем

мире. Так, в 1977 году была организована компания Relational

Software Inc. (ныне Oracle Corporation), чтобы создать реляци-

онную СУБД, основанную на SQL. Эта СУБД, названная

Oracle, первой вышла на рынок в 1979 году.

Аналогично исследовательской группе компании IBM, в уни-

верситете города Беркли (штат Калифорния) создали прототип

реляционной СУБД, назвав свою систему Ingres, который вклю-

чал в себя язык запросов QUEL. В 1980 году несколько специали-

стов покинули Беркли и основали компанию Relational

Technology, Inc., чтобы создать коммерческую версию системы

Ingres, поставки которой на рынок начались в 1981 году. Компа-

ния Relational Technology, переименованная в 1989 году в Ingres

Corporation, остается ведущим поставщиком реляционных СУБД,

внеся в систему ряд усовершенствований. Например, в 1986 году

первоначальный язык запросов QUEL был с успехом заменен на

SQL.

Фирма ШМ в 1981 году выпустила коммерческий продукт на

основе System/R, который получил название SQL/Data System

(SQL/DS), а в 1983 году появилась еще одна реляционная СУБД -

Database 2 (DB2). DB2 являлась ведущей реляционной СУБД

компании IBM, и язык SQL этой системы стал фактическим стан-

дартом для БД. Технология, реализованная в DB2, затем была

использована в программных продуктах всех направлений ком-

пании ЮМ, от персональных компьютеров до сетевых серверов и

больших ЭВМ.

В течение первой половины 80-х годов поставщики реляцион-

ных БД боролись за признание своих продуктов, т.к. в сравнении

с традиционными архитектурами БД, реляционные программные

продукты имели несколько недостатков, например, производи-

тельность реляционных БД была ниже; чем у традиционных. Од-

нако у реляционных систем было большое преимущество: их

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

без написания программ и немедленно получать результаты.

Во второй половине 80-х годов реляционные БД уже стали

считаться технологией будущего, появились новые версии СУБД

Ingress и Oracle, производительность которых была в два-три раза

выше, чем у предыдущих версий. Опубликование в 1986 году

стандарта SQL, принятого ANSI/ISO, официально закрепило за

SQL статус стандарта. Кроме того, данный статус был определен

для компьютерных систем на основе ОС UNIX, рост популярно-

сти которых пришелся на конец 80-х.

С увеличением мощности компьютеров и объединения их в

локальные сети, возникла необходимость в сложных СУБД для

персональных компьютеров. Поставщики таких СУБД при

создании новых систем положили в их основу SQL, а постав-

щики СУБД для мини-компьютеров вышли на зарождающийся

рынок локальных вычислительных сетей. В начале 90-х усо-

вершенствование реализации SQL и появление более мощных

процессоров позволили применять этот язык в приложениях

для обработки транзакций. Теперь SQL стал ключевой частью

архитектуры клиент/сервер, связывающей сетевой сервер и

персональные компьютеры в систему, в которой обработка

информации происходит со сравнительно небольшими затра-

тами. По этой причине во все новые СУБД стали вводить под-

держку SQL, ведь он стал как официальным, так и фактиче-

ским стандартом для реляционных БД.

Важнейшим шагом к признанию SQL стало появление

стандартов на этот язык. Традиционно при упоминании стан-

дарта SQL имеют в виду официальный стандарт, утвержден-

114

Часть II. Структурированный язык запросов SQL

ный ANSI/ ISO. Однако существуют и другие важные стандар-

ты SQL, включая реализацию в системе DB2 компании ЮМ, и

стандарт X/OPEN для SQL в среде UNIX.

В 1982 году началась работа ANSI над официальным стандар-

том языка реляционных БД, и комитет остановил свой выбор на

SQL. В основу стандарта был положен SQL системы DB/2, несмотря

на то, что он содержал в себе ряд существенных отличий от этого

диалекта языка. После нескольких доработок, в 1986 году стандарт

был официально утвержден как стандарт ANSI номер Х3.135, а в

1987 году - в качестве стандарта ISO. Затем стандарт ANSI/ISO был

принят правительством США, как FTPS - федеральный стандарт

США по обработке информации, который несколько переработан-

ный в 1989 году, обычно называют стандартом SQL-89 или SQL1.

Отличия между диалектами SQL в СУБД различных производите-

лей не помешали комитету: он обошел некоторые из них, не стан-

дартизировав определенные части языка. Это позволило объявить

большое число реализаций SQL совместимыми со стандартом, од-

нако сделало сам стандарт относительно слабым. По этой причине

ANSI продолжил свою работу и создал проект нового, более жест-

кого стандарта SQL2, а для следующего за ним стандарта SQL3 бы-

ли предложены другие серьезные изменения. В результате предло-

женные стандарты SQL2 и SQL3 оказались еще более противоречи-

выми, чем исходный стандарт. Стандарт SQL2 утвержден в ANSI и

окончательно принят в октябре 1992 года.

Управление базами данных с помощью SQL

Как уже было замечено выше, реляционная БД - это связанная

информация, сохраняемая в двумерных таблицах со строками и

столбцами. Каждая строка, в терминах СУБД обычно называемая

записью, будет соответствовать определенной особенности дан-

ных, например, набору информации об успеваемости конкретно-

го студента по тому или иному учебному предмету. Каждый

столбец таблицы, называемый полем, будет содержать значение

для каждого типа данных - например, имени студента, представ-

ляемого в каждой строке. Таким образом, основой реляционной

БД является двумерная таблица с информацией.

Однако реляционные БД редко состоят из одной таблицы. Для

выполнения более сложных и мощных операций с данными соз-

дают несколько таблиц взаимосвязанной информации. Мощность

БД зависит от связи, которую определяют между фрагментами

Глава 2.1. Введение в SQL

115

информации, а не от самого этого фрагмента. При этом для под-

держания максимальной гибкости системы, строки таблицы не

должны находиться ни в каком определенном порядке. В систе-

мах с реляциотшой БД имеется мощная функция упорядочивания

(индексирования) информации с возможностью последующего ее

восстановления.

В таблицах БД необходимо иметь столбец, который бы уникаль-

но идентифицировал каждую строку. Обычно этот столбец содер-

жит номер, например, номер студенческого билета. Такой уникаль-

ный столбец (или уникальная группа столбцов), используемый, что-

бы идентифицировать каждую строку и хранить все строки отдель-

но, называется первичным ключом таблицы.

Первичные ключи таблицы важный элемент в структуре

БД. Они являются основой системы записи в файл; и когда

возникает необходимость найти определенную строку в таб-

лице, то к ней ссылаются по этому первичному ключу. Кроме

того, первичные ключи гарантируют, что данные имеют опре-

деленную целостность. Если первичный ключ правильно ис-

пользуется и поддерживается, то всегда будет доступна ин-

формация о том, что нет пустых строк таблицы и что каждая

строка отличается от любой другой строки.

В отличие от записей, поля таблицы упорядочиваются и име-

нуются. Это означает, что каждый столбец данной таблицы дол-

жен иметь уникальное имя, чтобы избежать неоднозначности.

Лучше всего, если эти имена указывают на содержание поля.

SQL обычно работает в компьютерных системах, которые

имеют более одного пользователя, и, следовательно, возникает

необходимость различать их между собой. Обычно в такой системе

каждый пользователь имеет некий код проверки прав, который его

идентифицирует. В начале сеанса с компьютером, пользователь

входит в систему (регистрируется), сообщая компьютеру опреде-

ленный Ш (идентификатор). Любое количество людей, исполь-

зующих тот же самый Ш доступа, являются отдельными пользова-

телями; и аналогично, один человек может представлять большое

количество пользователей в разное время, используя различные

идентификаторы.

Действия в большинстве сред SQL разрешены в соответствии

со специальным идентификатором, который точно определяет

пользователя. Таблица или другой объект принадлежит пользова-

телю, который имеет над ним полную власть. При этом пользова-

тель может иметь привилегии для выполнения действий над объ-

116

Часть II. Структурированный язык запросов SQL

ектом. В большинстве случаев в приводимых примерах будем

считать, что любой пользователь имеет привилегии, необходи-

мые для выполнения любого действия.

Описание учебной базы данных

В дальнейшем изложении будем использовать в качестве

примера небольшую БД, отражающую учег успеваемости студентов

ВУЗа, несколько модифицированную по сравнению с используемой

в первой части книги. В ней содержится четыре таблицы.

В таблице СТУДЕНТЫ (STUDENTS) содержится пять полей с

информацией о студентах:

• SNUM - номер студенческого билета;

• SFAM - фамилия студента;

• SIMA - имя студента;

• SOTCH - отчество студента;

• STIP - размер получаемой студентом стипендии.

Таблица 2.1

Студенты

STUDENTS

SNUM

3412

3413

3414

3415

3416

SFAM

Поляков

Старова

Гриценко

Котенко

Нагорный

SIMA

Анатолий

Любовь

Владимир

Анатолий

Евгений

SOTCH

Алексеевич

Михайловна

Николаевич

Васильевич

STIP

25.50

17.00

0.00

25.50

Таблица 2.2

Предметы

PREDMET

PNUM

2001

2002

PNAME

Физика

Химия

TNUM

4001

4002

HOURS

COURS

Глава 2.1. Введение в SQL

117

PNUM

2003

2004

2005

PNAME

Математика

Философия

Экономика

PREDMET

TNUM

4003

4005

4004

HOURS

COURS

Таблица 2.3

Преподаватели

TEACHERS

TNUM

4001

4002

4003

4004

4005

TFAM

Никулина

Костыркин

Казанко

Позднякова

Загарийчук

TIMA

Валентина

Олег

Виталий

Любовь

Игорь

ТОТСН

Ивановна

Владимиро-

вич

Владимиро-

вич

Алексеевна

Дмитриевич

TDATE

01/04/1984

01/09/1997

01/09/1988

10/05/1989

Таблица 2.4

Успеваемость

USP

UNUM

1001

1002

1003

1004

1005

OCENKA

UDATE

10/06/1999

11/06/1999

12/06/1999

SNUM

3412

3413

3414

3412

3416

PNUM

2001

2003

2005

2003

2004 •

118

Часть II. Структурированный язык запросов SQL

В таблице ПРЕДМЕТЫ (PREDMET), состоящей го пяти по-

лей, содержится информация об учебных предметах. Назначение

полей таблицы следующее:

• PNUM - номер (код) учебного предмета;

• PNAME - наименование учебного предмета;

• TNtM - номер (код) преподавателя;

• HOURS - продолжительность учебной дисциплины в часах;

• COURS - курс, на котором ведется данный учебный

предмет.

В таблице ПРЕПОДАВАТЕЛИ (TEACHERS), состоящей из

пяти полей, содержится информация о преподавателях. Поля таб-

лицы следующие:

• TNUM - код преподавателя;

• TFAM - фамилия преподавателя;

• TIMA - имя преподавателя;

• ТОТСН - отчество преподавателя;

• TDATE - дата принятия преподавателя на работу.

В таблице УСПЕВАЕМОСТЬ (USP), состоящей из пяти по-

лей, хранится информация об успеваемости студентов по учеб-

ным дисциплинам. Поля таблицы следующие:

• UNUM - код факта сдачи учебной дисциплины;

• OCENKA - оценка, полученная студентом по учебному

предмету;

• UDATE - дата сдачи;

• SNUM - номер студенческого билета;

• PNUM - код учебного предмета.

Структура операторов и базовые; элементы^ языка

У каждого объекта в БД есть уникальное имя. Имена исполь-

зуются в операторах SQL и указывают, над каким объектом базы

данных оператор должен выполнить действие. В стандарте

ANSI /ISO определено, что имена имеются у таблиц, столбцов и

пользователей. Во многих диалектах SQL поддерживаются также

дополнительные именованные объекты, такие как хранимые про-

цедуры, именованные отношения и формы для ввода данных.

Глава 2 1. Введение в SQL

119

В соответствии со стандартом ANSI/ISO, в SQL имена должны

содержать от 1 до 18 символов, начинаться с буквы и не содержать

пробелы или специальные символы пунктуации. В стандарте SQL2

максимальное число символов в имени увеличено до 128. при этом

на практике в различных СУБД разрешено использование в именах

таблиц специальных символов. Поэтому для повышения переноси-

мости лучше делать имена сравнительно короткими и избегать ис-

пользования в них специальных символов.

Если в каком-либо операторе указано имя таблицы, SQL пред-

полагает, что происходит обращение к одной из собственных

таблиц пользователя. Имея соответствующее разрешение, можно

обращаться к таблицам, владельцами которых являются другие

пользователи, с помощью полного имени таблицы.

Полное имя состоит из имени владельца таблицы и собствен-

но ее имени, разделенных точкой. Например, полное имя табли-

цы USP, владельцем которой является пользователь по имени

DENIS, имеет следующий вид:

DENIS.USP

Полное имя можно использовать вместо простого имени таб-

лицы во всех операторах SQL. Если в операторе задается имя

поля, SQL сам определяет, в какой из указанных в этом же

операторе таблиц содержится данное поле. Однако, если в

оператор требуется включить два поля из различных таблиц,

но с одинаковыми именами, необходимо указать полные%ме-

на, которые однозначно определяют их местонахождение.

Полное имя поля состоит из имени таблицы, содержащей

столбец, и имени поля, разделенных точкой. Например, полное

имя поля OCENKA из таблицы USP имеет следующий вид:

USP.OCENKA

Если поле находится в таблице, владельцем которой является

другой пользователь, то в полном имени следует также указать

имя пользователя. Например, полное имя поля OCENKA из таб-

лицы USP, владельцем которой является пользователь DENIS,

имеет следующий вид:

DENIS.USP.OCENKA

Полное имя поля можно использовать вместо простого имени

во всех операторах SQL; об исключениях говорится при описа-

нии конкретных операторов.