3.1.4. Реляционная модель

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

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

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

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

3.2. Архитектуры субд

Местоположение баз данных зависит от используемой архитектуры. Имеются следующие разновидности архитектур баз данных:

• архитектура «мэйнфрейм»;

• «локальные» базы данных;

• архитектура «файл-сервер»;

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

• многозвенная архитектура.

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

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

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

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

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

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

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

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

• вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента;

• локальные СУБД используют навигационный подход, ориентируемый на работу с отдельными записями;

• неоптимально расходуются ресурсы клиентского компьютера и сети, так как вне зависимости от количества запрашиваемых записей, на компьютер клиента копируется вся база данных, что с возрастанием объема обрабатываемой информации вызывает потребность в постоянном увеличении его вычислительных мощностей. При одновременной работе в сети и обращении к файловому серверу большого числа рабочих станций, сеть быстро насыщается, ее трафик становится узким местом, ухудшая производительность работы системы в целом;

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

• возможность нарушения смысловой целостности информации, так как управление целостностью БД реализуется в клиентском приложении, что позволяет в разных приложениях, работающих с одной базой данных, проектировать взаимоисключающие правила контроля целостности данных;

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

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

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

• управление одной информационной базой данных, с которой совместно работают множество пользователей;

• управление доступом к БД;

• защита информации в БД с помощью средств архивации/восстановления и создания резервных копий;

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

Клиентское приложение («внешний интерфейс») - это часть системы, которую пользователь использует для взаимодействия с данными.

Клиентские приложения в СУБД «клиент-сервер» выполняют следующие задачи:

• представление интерфейса, с помощью которого пользователь может выполнять свою работу;

• управление логикой приложения;

• выполнение логики приложения;

• проверка допустимости данных;

• запрос и получение информации от сервера базы данных.

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

Кроме того, данная модель обладает хорошей адаптируемостью и гибкостью в случае неизбежных изменений в программном и аппаратном обеспечении. Еще одним из достоинств является то, что система «клиент-сервер» легко масштабируется, приспосабливаясь к изменениям в рабочей группе.

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

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