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

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

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

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

ФОРМА – элемент обеспечивающий визуализацию записей таблиц и результатов выполнения запросов, имеющий также возможность включения специальных элементов управления (кнопок, переключателей), позволяющих вводить данные в базу, запускать какие-либо программы, открывать другие формы.

ОТЧЕТ – элемент СУБД представляющий собой представление информации, хранящейся в базе, в виде, пригодном для печати или передачи в другие программные оболочки (в Word, Excel).

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

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

СУБД с централизованной архитектурой.

СУБД с архитектурой файл-сервер.

СУБД с архитектурой клиент-сервер.

СУБД с трехуровневой архитектурой: " тонкий клиент" — сервер приложений — сервер базы данных. В СУБД с централизованной архитектурой. СУБД и сама база данных размещается и функционирует на центральном миникомпьютере (мэйнфрейме), а пользователи получают доступ к базе данных при помощи обычных терминалов - компьютер рассматривается просто как устройство ввода и отображения информа­ции: на мэйнфрейм передаются нажатия клавиш, в обратном направлении передаются данные, отображае­мые непосредственно на мониторе пользователя. Примерами СУБД с централизованной архитектурой являются ранние версии СУБД DB2, ранние версии СУБД Oracle и Ingres.

Рис. 2.7. Централизованная архитектура

В СУБД с архитектурой файл-сервер база данных хранится на сервере, а копии СУБД устанавли­ваются на компьютерах пользователей. Файл базы данных, находящийся на сервере, совместно использует­ся всеми пользователями одновременно, при помощи сетевого программного обеспечения и самой опера­ционной системы. Ярким примером такой архитектуры является СУБД MS Access: копии СУБД установ­лены на компьютере каждого пользователя, а сам файл базы данных находится на сервере в сетевой папке.

Рис. 2.8 Файл-серверная архитектура

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

При архитектуре клиент-сервер база данных хранится на сервере, а СУБД подразделяется на две части: клиентскую и серверную. Клиентская часть СУБД выполняется на стороне клиента и обеспечивает интерактивное взаимодействие с пользователем и формирование запросов к базе данных (на языке SQL). Серверная часть работает на сервере и взаимодействует с базой данных, обеспечивая выполнение запросов клиентской части. Т.е., если провести аналогию с рассмотренным выше примером, то клиентская часть сформирует и отправит серверной части запрос " Отбери для меня строки таблицы с товарами, по которым объем продаж не превышает 100 тыс. руб", серверная часть выполнит данный запрос и отошлет клиентской части только те строки, которые необходимо, не передавая по сети все строки таблицы. Большинство современных СУБД реализованы по архитектуре клиент-сервер: Oracle, MS SQL Server, PostgreSQL, MySQL, Informix, DB2 и др.

Рис. 2.9 Архитектура клиент-сервер

Однако и архитектура клиент-сервер не лишена недостатков. Если деловая логика взаимодействия с базой данных (логика, определяющаяся порядком работы предприятия: какие таблицы и в каком порядке заполнять, что делать при добавлении нового сотрудника и т.д.) изменяется, то приходится заново перепи­сывать клиентские программы (вводить новые формы, менять порядок их заполнения и т.д.). Если измене­ния происходят слишком часто, а количество рабочих мест велико, то постоянная переустановка програм­много обеспечения (которая, кстати, должна осуществляться достаточно быстро) становится серьезной проблемой. В таких случаях следует переходить к трехуровневой архитектуре: " тонкий клиент" — Web-сервер — сервер базы данных. При трехуровневой архитектуре в функции клиентской части (" тонкий клиент") входит только интерактивное взаимодействие с пользователем, а вся деловая логика вынесена в серверную часть, которая собственно и обеспечивает формирование запросов к базе данных, передавае­мых на выполнение. " Тонкий клиент" находится на компьютере пользователя и чаще всего представляет из себя Web-броузер (например, Internet Explorer), с помощью которого осуществляется доступ с специальной HTML-странице, размещенной в сети (на Web-сервере), после чего возможно с применением в соответствующей HTML-странице апплетов Java или компонентов ActiveX дистанционно запускать специальные микропрограммы, обращающиеся к системе управления базой данных, для создания запросов и редактирования базы данных. Таким образом, Web-сервер осуществляет связь между пользователями (клиентами и сервером базы данных).

Рис. 2.10 Трехуровневая архитектура

Преимущества трехуровневой архитектуры очевидны: при необходимости изменений в структуре или программной оболочке базы данных изменения вносятся только один раз — на сервере базы данных. Изменять или переустанавливать клиентские программы нет никакой необходимости.