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

Реляционной модели системы БД посвящена основная часть этой книги (базовые реляционные понятия вводятся в главе 3). SQL (язык структурированных запросов) будет рассматриваться, начиняя с главы 5. Здесь мы дадим лишь краткое введение в отношения, чтобы читатель мог почувствовать простоту модели, и приведем пример SQL, показывающий, как реляционная модель поддерживает запросы очень высокого уровня, позволяя избегать деталей нанигнции в БД.

Пример 1.1. Отношения - это таблицы. Заголовками их столбцов являются атрибуты, описывающие вхождения данных в эти столбцы. Например, отношение с именем Accoums, описывающее банковские счета, их балансы и типы, может иметь вид:

Заголовками столбцов являются три атрибута: accouniNo, balance и type. Под атрибутами расположены строки, или кортежи. Здесь явно показаны два кортежа данного отношении, а точки под ними означают, что может быть множество кор-гежс(1 - по одному для каждого банковского счета. Первый кортеж показывает, что баланс счета пол номером 12345 равен $1000 и этот счет является сберегательным, а nropofi кортеж означает, что счет 67890 является чековым счегом на сумму S2S46.92.

Предположим, нужно узнать баланс счета 67890. Можно сформулировать запрос в SQL:

SELECT balance FROM Accounts WHERE accountNo = 67890.

С помощью другого запроса можно потребовать сберегательные счета с отрицательным балансом:

SELECT accountNo FROM Accounls

WHERE type = savings AND balance < 0;

Мы понимаем, что двух приведенных примеров недостаточно для того, чтобы читатель стал экспертом по программированию в SQL, но они тем не менее демонстрируют высокий уровень операторов SQL типа seleci-froni-where. В принципе они просят систему БД:

1. Проверить все кортежи отношения Accounts, упомянутые л пункте FROM.

2. Выбрать кортежи, уяовлетворяюшие определенному критерию, указанному в пункте WHERE.

3. Выдать в качестве ответа определенные атрибуты этих кортежей, указанные в пункте SELECT.

На практике система должна оптимизировать запрос и найти эффективный способ отпета на него, даже если отношения, включенные в запрос, очень велики. □

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

1.1.3 Уменьшение размеров систем

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

1.1.4 Увеличение размеров систем

Опнако в гигабайте умещается не так уж много информации. Корпорат1ишые БД иногда занимают сотии гигабайт. Поскольку память сгамовизси все дешевле, находятся вес новые основания для хранения бо.пьших массивов .чанных. Например ceiH розничной торговли часто .хранят терабайт (1000 Гбайт, или 105 120 байт)

и лиже больше информации, отражаюшеи историю каждой продажи за длительный период времеци (для планирования инвентаризации; более подробно об этом будет сказано в разделе 1.3.4). БД больше не концентрируются на хранении простых элементов данных типа целых чисел или коротких строк символов, а могут хранить образы, аудио- и видеоин(1юрмацию, а также другие типы информации, требуюшие огромного пространства памяти. Например, один час видео требует гигабайта памяти. Ожидается, что к 2000 году БД, хранящие информацию со спугников, будут достигать нескольких петабайт (1000 терабайт, или 105 150 байт).

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

Дополнительные носители памяти

Самым большим на сегодняшний день БД требуется нечто большее, чем диски. Поэтому были созданы различные дополнительные носители памяти, каждое из которых может хранить терабайт. /1ля доступа к нему нужно больше времени, чем для доступа к лиску. Для доступа к любому элементу данных на типичном диске достаточно 10 - 20 мс, а для доступа к дополнительному носителю памяти может понадобиться несколько секунд. Такое устройство включает в себя транспортировку объекта, на котором хранится нужный элемент данных, на считывающее устройство. Это перемещение выполняется роботом-передатчиком определенного типа.

Например, дополнительными носителями памяти могут быть компакт-диски. Указанный на дорожке автомат перемешается к конкретному CD. выбирает его и загружает в считывающее устройство.

Параллельные вычисления

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

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

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