Эволюция баз данных

Чена. За исключением MS Visio, все средства обеспечивают преобразование построенной концептуальной схемы в физическое описание базы данных на языке SQL выбранной СУБД.

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

3.2. Методы хранения и доступа к данным

Архитектура первых баз данных 1970-х гг. достаточно проста. База данных хранилась во внешней памяти центральной ЭВМ типа IBM 360/370, PDP-11 или их советских аналогов ЕС и СМ ЭВМ. Доступ к данным осуществлялся через прикладные программы, которые запускались в пакетном (без участия пользователя) или в интерактивном (через удаленный дисплей, не обладающий собственными вычислительными мощностями) режиме. Современная база данных может по частям храниться на серверах разных континентов, обеспечивая одновременный доступ к данным миллионам пользователей по всему миру. Рассмотрим классификацию (рис. 29, [3]) и различные режимы хранения и доступа к данным.

Рис. 29. Классификация режимов хранения и доступа к данным

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

61

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

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

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

Архитектура «клиент-сервер»

Путь от однопользовательских централизованных до многопользовательских распределенных с параллельным доступом СУБД прошли еще на больших ЭВМ. Так, в 1970-е гг. на IBM 370 эксплуатировалось семейство многозадачных операционных систем MVT и MVS, позволявших запускать с удаленных терминалов одновременно несколько приложений, получавших свой независимый виртуальный ресурс. Распространение персональных ЭВМ ненадолго вернуло однопользовательскую централизованную архитектуру баз данных. Многие информационные системы 80-х – начала 90-х гг. создавались для персональной работы одного пользователя. Однако с ростом масштабов систем (от локальных персональных до интегрированных на уровне предприятия) потребовалось обеспечить единое информационное пространство, т.е. единую базу данных для всех пользователей системы.

Архитектура, обеспечивающая параллельный доступ удаленных пользователей к единому ресурсу, получила название клиентсерверной. Термин «клиент-сервер» с 1990-х гг. применяется для обозначения архитектуры программного обеспечения, состоящего из клиентского и серверного процессов [13]. Клиентский процесс запрашивает некоторые услуги, а серверный обеспечивает их выполнение. Применительно к базам данных модель «клиентсервер» воплощается в виде широкого спектр архитектур, допускающих различное распределение функций между клиентом и сервером.

62

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

ная на модели удаленного управления данными26 (рис. 30,а). При такой архитектуре на файловом сервере (как правило, специальном выделенном компьютере) централизованно хранятся файлы базы данных предприятия. Эти файлы могут через сеть передаваться на другие компьютеры. На каждом из этих компьютеров установлена СУБД, поддерживающая свою базу данных и обеспечивающая решение определенных прикладных задач. Запрос, поступающий от приложения, СУБД преобразует с языка манипулирования данными (на сегодняшний день это SQL) в команду на получение соответствующего файла базы данных и отправляет эту команду серверу. Получая от сервера файл или его часть, СУБД вместе с приложением выполняет обработку и изменение данных, после чего возвращает файл на сервер для поддержания центральной базы данных в актуальном состоянии. Очевидный недостаток такой архитектуры – большие объемы передаваемой по сети информации.

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

дель удаленного доступа к данным (RDA, Remote Data Access) (рис. 30,б). При такой архитектуре на сервере хранится база данных и установлено ядро СУБД. Языком взаимодействия клиента и сервера является SQL. Приложение генерирует SQL-запросы, в ответ на которые СУБД отправляет приложению требуемые данные.

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

ных (DBS, Database Server) (рис. 30,в). В этой архитектуре на сер-

вере наряду с данными стали храниться и другие объекты – процедуры и триггеры.

Процедуры или, точнее, хранимые процедуры (stored procedure,

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

26Более распространенное название – файл-серверная архитектура (FS, File Server).

27В зависимости от конкретной СУБД хранимые процедуры могут иметь другое название, например, функция, определенная пользователем (user defined function, англ.).

63

а) б)

в) г)

Рис. 30. Модели удаленного управления данными – FS (а), удаленного доступа к данным – RDA (б), сервера базы данных – DBS (в), сервера приложений –

AS (г)

64

пример, Java или C). Хранимые процедуры предназначены для выполнения определенных действий над данными. При такой архитектуре клиентское приложение обращается к серверу с командой запуска соответствующей процедуры, а сервер возвращает требуемые данные или результаты их обработки.

Примером хранимой процедуры является процедура расчета средней заработной платы работников определенного отдела за определенный период времени. Входными параметрами этой процедуры являются название отдела, начало и окончание расчетного периода; выходным параметром – значение средней заработной платы. Отсутствие такой процедуры на сервере означало бы, что клиент должен запросить помесячную зарплату всех сотрудников отдела, после чего самостоятельно рассчитать среднее значение. Если такой расчет требуется нескольким клиентам, то каждый из них должен иметь в своем составе соответствующий программный код и каждому должны быть переданы сведения об индивидуальных помесячных зарплатах. Это не только повышает трафик, но и снижает гибкость системы.

Одним из видов хранимых процедур являются триггеры (trigger, англ.), предназначенные, как правило, для обеспечения целостности данных. Исполнение триггеров активируется при наступлении определенного события, например, при попытке удалить или модифицировать данные. Триггеры могут также контролировать семантическую целостность и непротиворечивость данных. Например, из табл. 23, 24 следует, что на содержание существующих в аналитическом отделе работников уходит 54 тыс. руб. из имеющихся 70 тыс. руб. Это означает, что при приеме нового работника его оклад может составлять не более 16 тыс. руб. Специальный триггер способен выявить и заблокировать попытку ввода значения, превышающего это ограничение.

В реляционных базах данных триггеры привязываются к определенным таблицам или представлениям и контролируют операции, затрагивающие именно эти таблицы.

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

65

ние «сервер приложений». Этот сервер предназначен для решения прикладных задач пользователей. Для получения необходимых данных он взаимодействует с сервером базы данных в соответствии с моделью RDA или DBS. Соответственно новая архитектура стала называться моделью сервера приложений (AS, Application Server) (рис. 30,г).

При такой архитектуре программное обеспечение клиента отвечает только за взаимодействие с пользователем, в то время как вся логика решения задач (так называемые бизнес-логика или биз- нес-правила) реализована на сервере приложений в виде процедур, называемых сервисами (service, англ.). При наличии сервера приложений часть хранимых процедур сервера базы данных может быть также перенесена на сервер приложений. Однако это влечет за собой увеличение трафика между двумя серверами. Чтобы этого не происходило, необходимо добиваться оптимального распределения процедур, исходя из того, что наиболее сложные с точки зрения логики и трудоемкости расчетов должны размещаться на сервере приложений.

Перечисленные модели дают лишь общее представление о различных принципах построения клиент-серверной архитектуры. Реализация этих принципов очень вариативна и зависит от используемых технологий и программных платформ. Для различения этих вариантов используются несколько критериев их классификацииТак, принято. разделять клиент-серверные модели на двух- и трехзвенные. Кроме того, принято различать «толстых» (fat client, англ.) и «тонких» (thin client, англ.) клиентов, в зависимости от числа выполняемых ими функций (табл. 25).

66

Варианты распределения функций между сервером и клиентом были предложены в 1995 г. в отчете американской компании Gartner Group, занимающейся консультированием и исследованиями в области информационных технологий. В соответствии с этой классификацией выделяются пять групп клиент-серверных архитектур

(рис. 31):

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

формируемым как на стороне сервера, так и на стороне клиента;

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

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

4)модель с удаленной базой данных, в которой все данные размещаются на сервере;

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

Распределение функций между компонентами системы легло также в основу классификации разновидностей трехзвенной архитектуры (рис. 32). Из рисунка видно, что наиболее «спорным» предметом распределения между звеньями системы являются процедуры обработки данных для решения прикладных задач.

3.3. Управление транзакциями

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

67

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

1.После ввода данных о банковской карточке происходит сбой вычислительной системы, например, отключение электропитания, сбой сети или сбой сервера авиакомпании. Что в результате: куплен ли билет, списаны ли деньги или все отменено? Может ли случиться так, что билет будет выписан (ведь резервирование уже произошло), а деньги не списаны?

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

Несмотря на то, что вопросы поддержания непротиворечивости данных обсуждались с начала 1970-х гг., технология обеспечения целостности базы данных, основанная на механизме «транзакций», появилась лишь в начале 80-х. Наиболее существенный вклад в ее развитие внес Джим Грэй (Jim Gray) – американский исследователь в области компьютерных наук и приложений компьютеров в науке (в частности, в астрономии и гидрологии). Работая над проектом System R в IBM, он заложил теоретические основы механизма транзакций, которые опубликовал в ряде отчетов и в докладе [24].

Транзакция (transaction, англ.) – это последовательность действий с базой данных, которая рассматривается как единое целое. К транзакции предъявляются следующие требования:

она должна быть выполнена полностью или не выполнена во-

обще (свойство атомарности, atomicity);

она должна переводить базу данных из одного непротиворечивого (согласованного) состояния в другое непротиворечивое состояние28 (свойство согласованности, consistency);

28Под состоянием базы данных понимается ее наполнение конкретными данными. Например, смена фамилии работника – это уже другое состояние базы данных.

69

транзакции, конкурирующие за доступ к одним и тем же объектам базы данных, должны обрабатываться последовательно и изолированно друг от друга (свойство изолированности, isolation);

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

В литературе перечисленные требования обозначаются аббревиатурой ACID. Поясним свойства согласованности и атомарности на первой ситуации с покупкой авиабилетов: пассажир покупает один билет, и при оплате происходит сбой системы. Оплата авиабилета осуществляется уже после того, как пассажиру выделено место в самолете, т.е. число свободных мест на данном рейсе уменьшилось на единицу. Если оплата не произойдет, то база данных окажется в несогласованном состоянии – авиакомпания лишилась места и не получила денег. Транзакция в данном случае должна включать в себя, по меньшей мере, три операции: выделение места пассажиру, списание денег с его банковской карты и зачисление денег на счет авиакомпании. Если хотя бы одна из этих операций не завершится, то база данных должна быть возвращена в исходное состояние.

Свойство изолированности поясним на второй ситуации: два пользователя одновременно пытаются купить по два билета при наличии всего трех свободных мест29. Транзакция первого пользователя должна «захватить» два места и не «отпускать» их до тех пор, пока она не завершится либо пока не произойдет отмена всех изменений и места будут возвращены. Однако пока эта транзакция не завершена и ее результаты не зафиксированы, второй пользователь должен «видеть» свободные места в том виде, в каком они были до начала этой транзакции первого пользователя.

Свойство долговечности иллюстрируется в работе [24] с помощью «житейского» примера – свадебной церемонии. Священник спрашивает присутствующих о наличии причин, препятствующих браку. После этого он по очереди задает вопрос жениху и невесте об их согласии вступить в брак. И наконец, в случае всех благоприятных ответов, он объявляет их мужем и женой, т.е. фиксирует транзакцию. И наоборот, если единодушие не достигнуто и нахо-

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

70