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

Г.М.Ладыженский

Oracle CIS, (+7 095) 258-41-80, glodigen@ru.oracle.com

1.1. Реляционная модель данных
1.2. Язык SQL

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

Случилось так, что представление о СУБД сложилось у большинства отечественных пользователей на основе опыта использования систем на платформе персональных компьютеров, таких как FoxBASE, Paradox, Clipper, dBASE, Clarion и т.д.

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

Начало активного использования персональных СУБД в нашей стране по времени совпадает с началом бума персональных компьютеров (1986-87 гг.), который сегодня, к счастью, постепенно спадает. За это время на их основе создано множество программ и выросло целое поколение разработчиков, ориентированных на них в своей профессиональной деятельности. Широкое распространение получили наивные представления о том, что персональный компьютер (и его программное обеспечение, в том числе и СУБД) представляет собой универсальное средство автоматизации, пригодное для использования в любых сферах человеческой деятельности, от самых простых и до самых сложных.

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

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

К счастью, положение дел изменяется к лучшему. В настоящее время большинство средних и крупных государственных и коммерческих организаций постепенно отказываются от использования только персональных компьютеров и начинают всерьез задумываться о создании действительно открытых и распределенных информационных систем на мощной компьютерной платформе. Переломным в этом смысле стал 1994 год, в течение которого в нашей стране можно было наблюдать взрыв интереса к многопользовательским СУБД. Сегодня, видимо, нет серьезных факторов, сдерживающих распространение таких систем, если не считать скромные финансовые возможности многих организаций и слабую информированность пользователей преимущественно в технологической сфере.

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

Мне хотелось бы поблагодарить всех, кто принимал участие в работе над статьями. Я особенно признателен Владимиру Елисееву, многочисленные консультации с ним помогли мне сформулировать основные концепции и изложить их максимально просто. Огромную помощь в работе оказал Григорий Барон, сделавший ряд ценных замечаний практически по всем важнейшим темам. Я хотел бы также выразить признательность фирмам Computer Associates, Informix Software и Novell за любезно предоставленные технические материалы, которые были использованы при подготовке статей.

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

Системы управления базами данных - коротко о главном:
Часть 1

Введение

Важнейшая задача компьютерных систем - хранение и обработка данных. Для ее решения были предприняты усилия, которые привели к появлению в конце 60-х - начале 70-х годов специализированного программного обеспечения - систем управления базами данных (DataGBase Management Systems - DBMS). СУБД позволяют структурировать, систематизировать и организовать данные для их компьютерного хранения и обработки. Сегодня невозможно представить себе деятельность любого современного предприятия или организации без использования профессиональных СУБД. Несомненно, они составляют фундамент информационной деятельности во всех сферах - начиная c производства и заканчивая финансами и телекоммуникациями.

Приступая к обсуждению проблем СУБД, необходимо прежде всего договориться о терминологии. Это и является задачей Раздела 1. В нем очень кратко рассматриваются основные понятия и определения, среди которых - база данных, сущности, атрибуты, связи. Основное внимание уделено реляционной модели данных и главным ее понятиям - таблица, столбец, строка, первичный ключ, внешний ключ, отношение, индекс. Очень сжато обсуждается язык SQL (Structured Query Language).

Сердцевиной, центральным компонентом любой СУБД является сервер базы данных. Его техническое качество в решающей степени определяет главные характеристики системы, такие как производительность, надежность, безопасность и т.д.. В то же время богатство и разнообразие возможностей, заложенных в механизм его функционирования, сильно сказываются на эффективности разработки прикладных программ. Модель взаимодействия "клиент-сервер", эволюция сервера БД, основные его возможности и тенденции обсуждаются в Разделе 2.

Сервер БД является неотъемлемым компонентом модели взаимодействия "клиент-сервер", которая стала фактическим стандартом архитектуры современных СУБД и одним из этапов их развития от систем с централизованной архитектурой и систем с файловым сервером. В то же время в рамках модели "клиент-сервер" претерпела изменения парадигма взаимодействия клиента и сервера. Эволюция сервера БД происходила от архитектуры "по одному серверу для каждого клиента" к многопотоковой, мультисерверной архитектуре.

Одна из главных тенденций сервера БД - усиление его активной роли в модели взаимодействия "клиент-сервер". Эта идея - не каприз разработчиков, не технический изыск и не упражнение для ума. Она была вызвана к жизни реальными практическими задачами, возникающими в самых различных областях информационной деятельности человека. Традиционное же решение этих задач в системах с пассивным сервером было громоздким и неэффективным и не удовлетворяло современным требованиям. Аргументы в пользу активного сервера БД - предмет Раздела 2, где обсуждаются потребности реальной жизни, недостатки традиционных систем, новые подходы, позволяющие их преодолеть, и конкретные механизмы, в которых они находят свое воплощение.

В Разделе 3 рассматриваются текущее состояние и перспективы распределенных баз данных. Вводится понятие распределенной БД, обсуждаются основные принципы обработки распределенных данных. Технология "клиент-сервер" невозможна без учета важнейших требований, в числе которых прозрачность расположения и прозрачность сети, автоматическое преобразование форматов данных и автоматическая трансляция кодов, организация доступа к неоднородным базам данных. автоматическая двухфазная фиксация транзакций, оптимизация распределенных запросов, поддержка словаря распределенных данных. Наряду с технологией распределенного хранения данных обсуждается активно развивающаяся в последнее время технология тиражирования данных.

Ввиду особой важности, обсуждение проблем обработки транзакций вынесено в Раздел 4. Сравнительно новая тема - мониторы транзакций. Описаны архитектура и основные возможности монитора транзакций на базе ОС UNIX.

В последнее время проблема безопасности в СУБД выдвинулась на первый план. Это - обширная тема, требующая особого обсуждения. В Разделе 5 затрагиваются лишь традиционные методы защиты данных в СУБД и современная концепция многоуровневой безопасности в базах данных.

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

Обращаясь к истории развития и совершенствования систем управления базами данных, можно условно выделить три основных этапа. Начальный этап был связан с созданием первого поколения СУБД, опиравшихся на иерархическую и сетевую модели данных (на основе спецификаций CODASYL). По времени он совпал с периодом, когда на рынке вычислительной техники доминировали большие ЭВМ (mainframe), например, система IBM 360/370, которые в совокупности с СУБД первого поколения составили аппаратно-программную платформу больших информационных систем.

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

С созданием реляционной модели данных был начат новый этап в эволюции СУБД. Простота и гибкость модели привлекли к ней внимание разработчиков и снискали ей множество сторонников. Несмотря на некоторые недостатки (у кого их нет?), реляционная модель данных стала доминирующей. Условно эту группу систем можно назвать "вторым поколением СУБД". Его характеризовали две основные особенности - реляционная модель данных и язык запросов SQL. Представители второго поколения в настоящее время еще сохраняют определенную популярность среди производителей СУБД, в большинстве своем развившись в системы третьего поколения, к которому и относятся современные СУБД.

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

На эволюции СУБД сильно сказался процесс перехода от больших ЭВМ к открытым распределенным системам на компьютерах RISC-архитектуры. По темпам развития RISC-компьютеры за последнее десятилетие существенно превзошли большие ЭВМ. Причинами того, что более половины обладателей больших ЭВМ заявили о намерении в ближайшее время отказаться от них в пользу открытых систем, послужили три фактора. Во-первых, цена RISC-компьютеров значительно ниже цены больших ЭВМ, и эта разница постоянно растет. Во-вторых, по функциональным возможностям RISC-компьютеры превзошли большие ЭВМ. В третьих, фактически сравнялась их производительность. Кроме того, архитектура систем на основе RISC-компьютеров оказалась более простой, гибкой и мобильной, а сфера их использования - значительно шире области применения больших ЭВМ.

Общая тенденция движения от отдельных mainframe-систем к открытым распределенным системам, объединяющим компьютеры среднего класса, получила название DownSizing. Этот процесс оказал огромное влияние на развитие архитектур СУБД и поставил перед их разработчиками ряд сложных проблем. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД, использовавшей собственные модели, форматы представления данных и языки доступа к данным и т.д., к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в глобальную сеть компьютеров различных моделей и производителей.

В то же время происходил встречный процесс - UpSizing. Бурное развитие персональных компьютеров, появление локальных сетей также оказали серьезное влияние на эволюцию СУБД. Высокие темпы роста производительности и функциональных возможностей PC привлекли внимание разработчиков профессиональных СУБД, что привело к их активному распространению на платформе настольных систем.

Сегодня возобладала тенденция создания информационных систем на такой платформе, которая точно соответствовала бы ее масштабам и задачам. Она получила название RightSizing (помещение ровно в тот размер, который необходим).

Однако и по нынешнее время большие ЭВМ сохраняются и сосуществуют с современными открытыми системами. Причина этого проста - в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства: в результате многие продолжают их использовать несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения представляет сам по себе сложную техническую проблему и требует значительных затрат.

Как же использовать ресурсы больших ЭВМ в современной организации? Один из возможных подходов заключается в интеграции больших ЭВМ и работающих на них СУБД в открытую распределенную среду обработки данных с помощью шлюзов (gateway). В этом случае большая ЭВМ может временно выполнять роль центрального компьютера, хранящего данные и предоставляющего их для обработки RISC-компьютерам, что будет происходить то тех пор, пока не будут созданы все условия для замены ее на высокопроизводительные компьютеры среднего класса.

Раздел 1. Реляционная база данных - основные понятия.

Часто, говоря о базе данных, имеют в виду просто некоторое автоматизированное хранилище данных. Такое представление не вполне корректно. Почему это так, будет показано ниже.

Действительно, в узком смысле слова, база данных - это некоторый набор данных, необходимых для работы (актуальные данные). Однако данные - это абстракция; никто никогда не видел "просто данные"; они не возникают и не существуют сами по себе. Данные суть отражение объектов реального мира. Пусть, например, требуется хранить сведения о деталях, поступивших на склад. Как объект реального мира - деталь - будет отображена в базе данных? Для того, чтобы ответить на этот вопрос, необходимо знать, какие признаки или стороны детали будут актуальны, необходимы для работы. Среди них могут быть название детали, ее вес, размер, цвет, дата изготовления, материал, из которого она сделана и т.д. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями - entities (пусть это слово не пугает читателя - это общепринятый термин), а их актуальные признаки - атрибутами (attributes).

Каждый признак конкретного объекта есть значение атрибута. Так, деталь "двигатель" имеет значение атрибута "вес", равное "50", что отражает тот факт, что данный двигатель весит 50 килограммов.

Было бы ошибкой считать, что в базе данных отражаются только физические объекты. Она способна вобрать в себя сведения об абстракциях, процессах, явлениях - то есть обо всем, с чем сталкивается человек в своей деятельности. Так, например, в базе данных можно хранить информацию о заказах на поставку деталей на склад (хотя он суть не физический объект, а процесс). Атрибутами сущности "заказ" будут название поставляемой детали, количество деталей, название поставщика, срок поставки и т.д.

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

Таким образом, в широком смысле слова база данных - это совокупность описаний объектов реального мира и связей между ними, актуальные для конкретной прикладной области. В дальнейшем мы будем исходить из этого определения, которое будет уточняться по ходу изложения.

1.1. Реляционная модель данных

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

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

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

Она была разработана Коддом еще в 1969-70 годах на основе математической теории отношений и опирается на систему понятий, важнейшими из которых являются таблица, отношение, строка, столбец, первичный ключ, внешний ключ.

Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка - конкретный объект. Так, таблица Деталь содержит сведения о всех деталях, хранящихся на складе, а ее строки суть набор значений атрибутов каждой конкретной детали. Каждый столбец таблицы - это совокупность значений конкретного атрибута объекта. Так, столбец Материал представляет собой множество значений "Сталь", "Олово", "Цинк", "Никель" и т.д. В столбце Количество содержатся целые положительные числа. Значения в столбце Вес суть вещественные числа, равные весу детали в килограммах.

Эти значения не появляются из воздуха. Они выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain). Так, значения в столбце материал выбираются из множества имен всех возможных материалов - пластмасс, древесины, металлов и т.д. Следовательно, в столбце Материал принципиально невозможно появление значения, которого нет в соответствующем домене, например, "вода" или "песок".

Каждый столбец имеет имя, которое обычно записывается в верхней части таблицы (рис.1). Оно должно быть уникальным в таблице, однако различные таблицы могут иметь столбцы с одинаковыми именами. Любая таблица должна иметь по крайней мере один столбец; столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от столбцов, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key). Рассмотрим пример, в котором база данных хранит информацию о рядовых сотрудниках (таблица Сотрудник) и руководителях (таблица Руководитель) в некоторой организации (рис.2). Первичный ключ таблицы Руководитель - столбец Номер (например, табельный номер). Столбец Фамилия не может выполнять роль первичного ключа, так как в одной организации могут работать два руководителя с одинаковыми фамилиями. Любой сотрудник подчинен единственному руководителю, что должно быть отражено в базе данных. Таблица Сотрудник содержит столбец Номер руководителя, и значения в этом столбце выбираются из столбца Номер таблицы Руководитель (см. рис.2). Столбец Номер Руководителя является внешним ключом в таблице Сотрудник.

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют "данные о данных", например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).

Помимо таблиц, в базе данных могут храниться и другие объекты, такие как экранные формы, отчеты (reports), представления (views) и даже прикладные программы, работающие с базой данных.

Для пользователей информационной системы недостаточно, чтобы база данных просто отражала объекты реального мира. Важно, чтобы такое отражение было однозначным и непротиворечивым. В этом случае говорят, что база данных удовлетворяет условию целостности (integrity).

Для того, чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).

Существует несколько типов ограничений целостности. Требуется, например, чтобы значения в столбце таблице выбирались только из соответствующего домена. На практике учитывают и более сложные ограничения целостности, например, целостность по ссылкам (referential integrity). Ее суть заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице. Ограничения целостности реализуются с помощью специальных средств, о которых речь пойдет в Разделе 2.

1.2. Язык SQL

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

Его появление и развитие как средства описания доступа к базе данных связано с созданием теории реляционных баз данных. Прообраз языка SQL возник в 1970 году в рамках научно-исследовательского проекта System/R, работа над которым велась в лаборатории Санта-Тереза фирмы IBM. Сегодня SQL - это фактический стандарт интерфейса с современными реляционными СУБД. Популярность его настолько велика, что разработчики не-реляционных СУБД (например, Adabas), снабжают свои системы SQL-интерфейсом.

Язык SQL имеет официальный стандарт - ANSI/ISO. Большинство разработчиков СУБД придерживается этого стандарта, однако часто расширяют его для реализации новых возможностей обработки данных. Новые механизмы управления данными, которые будут описаны в Разделе 2, могут быть использованы только через специальные операторы SQL, в общем случае не включенные в стандарт языка.

SQL не является языком программирования в традиционном представлении. На нем пишутся не программы, а запросы к базе данных. Поэтому SQL - декларативный язык. Это означает, что с его помощью можно сформулировать, что необходимо получить, но нельзя указать, как это следует сделать. В частности, в отличие от процедурных языков программирования (СИ, Паскаль, Ада), в языке SQL отсутствуют такие операторы, как if/then/else, for, while, break, continue и т.д.

Мы не будем подробно рассматривать синтаксис языка. Коснемся его лишь в той мере, которая необходима для понимания простых примеров. С их помощью будут проиллюстрированы наиболее интересные механизмы обработки данных.

Запрос на языке SQL состоит из одного или нескольких операторов SQL, следующих один за другим и разделенных точкой с запятой. Наиболее важные операторы SQL, которые входят в стандарт ANSI/ISO SQL, перечислены в табл.1.

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

В запросах на языке SQL используются имена, которые однозначно идентифицируют объекты базы данных. В частности, это - имя таблицы (Деталь), имя столбца (Название), а также имена других объектов в базе, которые относятся к дополнительным типам (например, имена процедур и правил), о которых речь пойдет в Разделе 2. Наряду с простыми, используются также сложные имена - например, квалификационное имя столбца (qualified column name) определяет имя столбца и имя таблицы, которой он принадлежит (Деталь.Вес). Для простоты в примерах имена будут записаны на русском языке, хотя на практике этого делать не рекомендуется. Имена выделены в тексте жирным шрифтом.

Каждый столбец в любой таблице хранит данные определенных типов. Различают базовые типы данных - строки символов фиксированной длины, целые и вещественные числа, и дополнительные типы данных - строки символов переменной длины, денежные единицы, дата и время, логические данные (два значения - "ИСТИНА" и "ЛОЖЬ"). В языке SQL можно использовать числовые, строковые, символьные константы и константы типа "дата" и "время".

Рассмотрим несколько примеров.

Запрос "определить количество деталей на складе для всех типов деталей" реализуется следующим образом:

SELECT Название, Количество 
FROM Деталь;
{ВЫБРАТЬ Название, Количество
ИЗ Деталь}

Результатом запроса будет таблица с двумя столбцами - Название и Количество, которые взяты из исходной таблицы Деталь. По сути, этот запрос позволяет получить вертикальную проекцию исходной таблицы (более строго, вертикальное подмножество множества строк таблицы). Из всех строк таблицы Деталь образуются строки, которые включают значения, взятые из двух столбцов - Название и Количество. 

Запрос "какие детали, изготовленные из стали, хранятся на складе?", сформулированный на языке SQL, выглядит так:

SELECT * 
FROM Деталь 
WHERE Материал = "Сталь";
{ВЫБРАТЬ ВСЕ 
ИЗ Деталь 
ГДЕ Материал = "Сталь"}

Результатом этого запроса также будет таблица, содержащая только те строки исходной таблицы, которые имеют в столбце Материал значение "Сталь". Этот запрос позволяет получить горизонтальную проекцию таблицы Деталь (звездочка в операторе SELECT означает выбор всех столбцов из таблицы).

Запрос "определить название и количество деталей на складе, которые изготовлены из пластмассы и весят меньше пяти килограммов" будет записан следующим образом:

SELECT Название, Количество 
FROM Деталь 
WHERE Материал = "Пластмасса"
AND Вес < 5;
{ВЫБРАТЬ Название, Количество 
ИЗ Деталь
ГДЕ Материал = "Пластмасса"
И Вес < 5 } 

Результат запроса - таблица из двух столбцов - Название, Количество, которая содержит название и число деталей, изготовленных из пластмассы и весящих менее 5 кг. По сути, операция выборки является операцией образования сначала горизонтальной проекции (найти все строки таблицы Деталь, у которых Материал = "Пластмасса" и Вес < 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

Одним из средств, обеспечивающих быстрый доступ к таблицам, являются индексы. Индекс - это структура базы данных, представляющая собой указатель на конкретную строку таблицы. Индекс базы данных используется так же, как индексный указатель в книге. Он содержит значения, взятые из одного или нескольких столбцов конкретной строки таблицы и ссылку на эту строку. Значения в индексе упорядочены, что позволяет СУБД выполнять быстрый поиск в таблице.

Допустим, что сформулирован запрос к базе данных Склад:

SELECT Название, Количество, Материал 
FROM Деталь 
WHERE Номер = "Т145-А8";
{ВЫБРАТЬ Название, Количество, Материал
ИЗ Деталь ГДЕ Номер = "Т145-А8"} 

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

Если же был предварительно создан индекс по столбцу Номер таблицы Деталь, то время поиска в таблице будет сокращено до минимума. Индекс будет содержать значения из столбца Номер таблицы Деталь и ссылку на строку с этим значением в таблице Деталь. При выполнении запроса СУБД вначале найдет в индексе значение "Т145-А8" (и сделает это быстро, так как индекс упорядочен, а его размер строки невелик), а затем по ссылке в индексе определит физическое расположение искомой строки.

Индекс создается оператором SQL CREATE INDEX (СОЗДАТЬ ИНДЕКС). В данном примере оператор

CREATE UNIQUE INDEX Индекс детали 
ON Деталь (Номер); 
{СОЗДАТЬ УНИКАЛЬНЫЙ ИНДЕКС Индекс детали 
ДЛЯ Деталь (Номер)} 

позволит создать индекс с именем "Индекс детали" по столбцу Номер таблицы Деталь.

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

Если в процессе выполнения этого действия произойдет сбой, например, когда первая операция будет выполнена, а вторая - нет, то деньги будут потеряны. Следовательно, любое действие над базой данных должно быть выполнено целиком, или не выполняться вовсе. Такое действие получило название транзакции.

Обработка транзакций опирается на журнал транзакций. В него заносится информация о каждой транзакции к базе данных. Она используется для отката транзакций и восстановления состояния базы данных. Более подробно о транзакциях будет сказано в Разделе 5.

Завершая обсуждение языка SQL, еще раз подчеркнем, что это - язык запросов. На нем нельзя написать сколько-нибудь сложную прикладную программу, которая работает с базой данных. Для этой цели в современных СУБД используется язык четвертого поколения (Forth Generation Language - 4GL), обладающий как основными возможностями процедурных языков третьего поколения (3GL), таких как СИ, Паскаль, Ада, так и возможностью встроить в текст программы операторы SQL, и средствами управления интерфейсом пользователя (меню, формами, вводом пользователя и т.д.). Сегодня язык 4GL - это один из фактических стандартов средств разработки приложений, работающих с базами данных.