Базы Данных - Сибилев, 2007

41

Приложение обеспечивает КП доступ только к той части БД орга-

низации, которая соответствует его обязанностям. Это и есть его база дан-

ных.

Приложение поддерживает только те манипуляции данными в БД,

которые обусловлены служебными функциями КП.

–Прикладные программисты — пользователи системы, создающие

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

тают с данными непосредственно. Их задачи – реализация алгоритмов об-

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

– Администратор базы данных — группа специалистов, проекти-

рующих, реализующих и сопровождающих систему. АБД несёт всю ответ-

ственность за функционирование и развитие системы.

3.5.3 Документация

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

Она обязательно должна включать описания

–правил регистрации пользователей в системе;

–правил использования отдельных инструментов СУБД или прило-

жений;

–процедуры запуска и останова системы;

–процедуры создания резервных копий БД;

–процедур обработки сбоев аппаратного и программного обеспече-

ния;

–процедур реструктурирования и реорганизации БД;

–способов улучшения производительности системы;

–методов архивирования данных на вторичных устройствах хране-

ния.

Документация создаётся вместе с системой и поддерживается в акту-

альном состоянии администратором базы данных.

42

3.5.4 Приложения

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

создание отчётов о контрактах и т.п. Приложение склада обеспечивает учёт поставок и отгрузки товаров, ведение складской ведомости и создание отчётов о движении товаров.

Приложение состоит из запросов, форм, отчётов, меню и приклад-

ных программ.

Запрос — это требование на выборку из БД подмножества данных,

удовлетворяющих определённым условиям. Запрос записывается на языке манипулирования данными, сохраняется в БД и может быть в дальнейшем активирован пользователем или прикладной программой по мере необхо-

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

тов.

Форма — это способ отображения данных пользователя в виде,

удобном для восприятия. Формы используются для просмотра, ввода и ре-

дактирования записей.

Отчёт — это форматированное отображение информации из БД.

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

просов в стандартной форме документа, принятой в организации. Отобра-

жаемые данные сгруппированы в разделы и очень часто агрегированы. От-

чёт содержит заголовки, колонтитулы и прочие атрибуты оформления до-

кумента. Приложение может вывести отчёт на печать, отобразить на экра-

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

Отчёт отображает состояние БД на момент его создания.

43

Типичные примеры отчётов: платёжные ведомости, счета, расчётные листки, складские ведомости и т.п.

Меню — это средства доступа к функциям приложения. С возможно-

стями механизма меню вы знакомы достаточно хорошо.

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

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

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

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

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

Конечные

пользователи

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

Приложение

склада

Рис. 3.6 Схема взаимодействия конечных пользователей с БД

3.6 Основные подсистемы СУБД

3.6.1 Подсистема проектирования

Подсистема проектирования (см. рис. 3.5) предназначена для созда-

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

44

− Языки определения данных (ЯОД) предоставляют средства описа-

ния элементов и структур данных, экранных форм и других параметров приложений.

− Языки манипулирования данными (ЯМД) обеспечивают навига-

цию в БД или формулирование запросов к данным.

− Языки программирования предназначены для написания приклад-

ных программ, обрабатывающих данные. Обычно коммерческие СУБД имеют средства для работы с несколькими системами программирования.

Многие современные СУБД имеют визуальные средства определе-

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

3.6.2 Подсистема обработки

Подсистема обработки (см. рис. 3.5) занимается обработкой компо-

нентов приложения. Так, при открытии формы процессор форм запраши-

вает её определение из раздела БД «Метаданные приложений», воспроиз-

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

Аналогичные функции выполняют процессор запросов и генератор отчётов. Процедурные средства предназначены для обработки запросов прикладных программ на чтение и запись данных.

3.6.3 Ядро СУБД

Ядро СУБД — это постоянно загруженная часть системы. Оно обес-

печивает интерфейс между БД и двумя другими компонентами СУБД. На-

пример, подсистема обработки принимает запрос приложения на считыва-

ние данных. Запрос сформулирован в терминах приложения. Подсистема обработки формулирует его в терминах логических единиц организации данных (например, таблиц) и передаёт ядру. Ядро преобразует запрос в по-

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

45

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

раторы определения структур данных, форм, запросов, отчётов. Эти опера-

торы ЯОД являются, по сути дела, запросами на обновление разделов сло-

варя данных. Подсистема проектирования интерпретирует их в терминах ЯМД и создаёт запросы на обновление соответствующих записей метадан-

ных. Запросы передаются ядру. Далее – как выше.

Кроме этого, ядро участвует в управлении транзакциями, санкцио-

нировании доступа к данным, резервном копировании и восстановлении БД.

3.7 Аппаратное обеспечение

Аппаратное обеспечение — это совокупность технических средств,

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

дельца.

Персональная система развёртывается на одном компьютере. Архи-

тектуры многопользовательских СБД весьма разнообразны. Выделяют два больших класса архитектур: системы с локальным доступом и системы с

удаленным (сетевым) доступом.

Системы с локальным доступом (рис. 3.7) разворачиваются на мощ-

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

собный выполнять какую-либо обработку данных. Он используется лишь для ввода и отображения данных. Системы с локальным доступом практи-

чески вышли из употребления.

В настоящее время СБД предприятий разворачиваются на компью-

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

лизованных БД с сетевым доступом (систем распределённой обработки данных).

		46
	РС1	РС2	. . .	РСn
Ц	ПП1	ПП2	. . .	ППn
е
н
т
р		СУБД
а
л
ь
н		ОС
а
я ЭВМ

БД

Рис. 3.7 СБД с локальным доступом

—с файловым сервером;

—с сервером базы данных.

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

пользуемая централизованная БД. Все другие узлы сети выполняют функ-

ции рабочих станций (клиентов). Они поддерживают доступ пользовате-

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

польно.

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

довательности команд чтения/записи файлов. ОС сервера считывает за-

прошенные файлы БД и передаёт их через сеть на клиентский узел. Кли-

ентская копия СУБД производит выборку и обработку данных, затребо-

ванную приложением. Если приложение выполняло обновление данных,

то обновлённые файлы возвращаются операционной системе сервера.

47

Клиент1				Клиент2				. . .		Клиентn
ПП1				ПП2						ППn
СУБД				СУБД						СУБД
				Сеть
	Файлы						Запросы файлов
				СЕРВЕР
				ОС

БД

Рис. 3.8 СБД с файловым сервером

Такая организация доступа имеет ряд недостатков. Один из них – высокий сетевой трафик. Запросы файлов, поступающие в сеть с клиент-

ских узлов, представляют собой последовательности низкоуровневых вы-

зовов. Сервер направляет в сеть необработанные файлы. Объёмы переда-

ваемых по сети данных оказываются очень большими. Время реакции сис-

темы на запрос клиента может оказаться неприемлемым для пользователя.

Второй, более существенный недостаток состоит в том, что в таких систе-

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

ционной системы сервера.

В архитектуре с сервером БД (см. рис. 3.9) на клиентских узлах раз-

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

борку данных на сервере. Результаты выборки (но не файлы!) передаются

48

по сети от сервера к клиенту. Такая организация распределённого доступа лишена выше перечисленных недостатков. Однако к производительности компьютера серверного узла здесь предъявляются повышенные требова-

ния.

Клиент1		Клиент2		. . .	Клиентn
ПП1		ПП2			ППn

Сеть

Данные

Запросы данных

СЕРВЕР

СУБД

ОС

БД

Рис. 3.9 СБД с сервером базы данных

Дальнейшим развитием стратегии «клиент-сервер» в области техно-

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

Сетевой трафик в СБД с сервером приложений значительно ниже, чем в СБД с сервером базы данных, однако требования к вычислительным ре-

сурсам серверного узла значительно выше.

3.8 Структурные единицы базы данных

Структурными единицами БД являются поле, запись и таблица.

49

Поле есть элементарная именованная единица логической организа-

ции данных, которая соответствует неделимой единице информации — ат-

рибуту (реквизиту). Для описания поля используются следующие обяза-

тельные характеристики:

−имя, например, ФИО

−тип, например, символьный, числовой, календарный;

−длина, определяемая максимально возможным количеством сим-

волов;

− точность для числовых данных.

Пример:

Фамилия CHAR(15), Дата_рождения DATA(8)

Каждое поле принимает значения из своего домéна – множества допус-

тимых значений.

Запись — это именованная совокупность логически связанных по-

лей. Запись понимается как структурный тип данных. Описание записи со-

ставляется из её имени и описаний полей. Например:

СТУДЕНТ(

номер_студбилета CHAR(7),

фамилия CHAR(20),

имя CHAR(15),

отчество CHAR(15),

номер_группы NUMERIC(5)

);

ГРУППА(

номер_группы NUMERIC(5),

год_набора DATA(4),

код_специальности NUMERIC(6)

);

50

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

Экземпляр записи — отдельная реализация записи, содержащая кон-

кретные значения ее полей (значение структурного типа данных). Напри-

мер, экземпляр записи СТУДЕНТ может быть таким:

‘440129К’ ‘Свидригайлов’ ‘Порфирий’ ‘Соломонович’ 10880

Таблица — это совокупность экземпляров записей одной структуры.

3.9 Ключи

Запись содержит поля, значения которых являются ключами.

Первичные ключи (Primary Key, PK) идентифицируют экземпляры записи. Т.е., файл не может содержать двух экземпляров записи с одинако-

выми значениями поля первичного ключа. В нашем примере такими поля-

ми являются СТУДЕНТ.НомерСтудбилета и ГРУППА.НомерГруппы. Первичные ключи используются для организа-

ции быстрого поиска отдельной записи и для организации связей экземп-

ляров записей. Заметим, что первичный ключ записи не может быть вы-

бран произвольно. Это должно быть поле (или группа полей), значения ко-

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

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

В структуре записи выделяют также поисковые поля, иногда назы-

ваемые вторичными ключами (Secondary Key, SK). Поисковые поля также используются для организации быстрого поиска записей, но значению по-

искового поля (вторичного ключа) в общем случае соответствует несколь-

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

Экземпляры записей могут быть связаны между собой по типу «роди-

тель – потомок». Связи обусловлены смыслом данных. Например, каждый экземпляр записи СТУДЕНТ связан как потомок с определённым экземпля-

ром записи ГРУППА. Используется несколько способов реализации связей