От правильного выбора инструментальных средств создания информационных систем, определения подходящей модели данных, обоснования рациональной схемы построения базы данных, организации запросов к хранимым данным и ряда других моментов во многом зависит эффективность функционирования разрабатываемых систем. Все это требует осознанного применения теоретических положений и инструментальных средств разработки баз данных и информационных систем.
При создании информационно-вычислительных систем, предполагающих обработку данных в базах, кроме выбора СУБД требуется решать проблему обоснования структуры программных и аппаратных средств. Для определения рациональной структуры программно-аппаратного обеспечения обработки данных в общем случае приходится отвечать на следующие вопросы:
- Какую структуру (однопотоковую или многопотоковую) имеет СУБД;
- применяются ли мониторы транзакций;
- можно ли использовать архитектуру клиент-сервер;
- сколько одновременно активных пользователей должна поддерживать система;
- можно ли из всего множества запросов выделить основной - шаблон (образец);
- какова стратегия индексации;
- какие запросы нужно поддержать индексацией, а какие можно реализовать с помощью сканирования базы данных;
- каков чистый размер базы данных;
- достаточно ли дисковых накопителей и интерфейсных адаптеров для обеспечения обработки предполагаемой нагрузки;
- имеются ли отдельные диски для журналов СУБД и архивов;
- достаточна ли емкость дисковой памяти для хранения данных, индексов, временных таблиц и для возможного увеличения объема данных;
- достаточно ли процессоров для работы с предполагаемым числом пользователей;
- требуется ли выделенная сеть для организации связи между клиентскими системами и сервером в системах клиент-сервер;
- согласована ли стратегия резервного копирования с типом, числом и местом размещения устройств резервного копирования.
Для получения ответа на перечисленные и подобные вопросы нужно прежде всего учитывать следующие факторы:
- 1) особенности прикладной задачи, а также методы и средства ее решения;
- 2) характеристики выбранной СУБД;
- 3) возможности и эффективность функционирования операционной системы;
- 4) характеристики аппаратной части и сетевого оборудования.
Важнейшей является задача распределения функций. По самой сути технологии на сервере расположена БД, а на компьютерах-клиентах — приложения. Однако при прямолинейных процедурах обеспечения целостности и запросах в сети может возникнуть объемный сетевой трафик. Чтобы его снизить, возможно использовать следующие рекомендации.
1. Обеспечение целостности для всех приложений лучше централизовать и осуществлять на сервере. Это позволит не только сократить трафик, но и рационально использовать СУРБД, улучшив управление целостностью (ссылочной, ограничений, триггеров) данных.
2. Целесообразно использовать на сервере хранимые процедуры, совокупность которых можно инкапсулировать в виде пакета (модуля). В результате трафик уменьшится: клиент будет передавать только вызов процедуры и ее параметры, а сервер — результаты выполнения процедуры.
3. В ряде случаев клиентам следует получать уведомления базы данных (например, заведующему складом — о нижнем уровне запасов, при котором следует выполнять новый заказ). Если уведомление производится по запросу клиента, трафик увеличивается. Проще эту (хранимую) процедуру разместить на сервере, который будет автоматически уведомлять клиента о возникновении события. В то же время клиент при необходимости может получать информацию с помощью простых вызовов процедур.
При решении задач определения структуры программно-аппаратных средств автоматизированной системы обработки данных в большинстве случаев в силу большой неопределенности и огромного числа противоречивых факторов для принятия решения достаточно экспертной оценки. Предположим, мы имеем клиент-серверную систему с выбранными и рационально сконфигурированными ОС и СУБД, а также эффективными приложениями. Стоит вопрос о том, какими возможностями должны обладать компьютеры этой распределенной системы с учетом имеющихся финансовых ограничений.
Вопрос распределения вычислительной мощности между клиентскими и серверными машинами, очевидно, следует решать под углом зрения используемой модели клиент-сервер. Более нагруженная часть системы должна быть обеспечена большими возможностями. При этом нужно учитывать специфику решаемых задач на клиентской и на серверной сторонах.
Ввиду большого разнообразия решаемых задач относительно клиентской части можно ограничиться общей рекомендацией: проанализировать потребности ресурсов ЭВМ и в пределах имеющихся финансов их удовлетворить. Например, приложения, требующие обработки видеоизображений, должны выполняться на компьютерах с хорошими характеристиками видеосистем (достаточным объемом видеопамяти, неплохим разрешением мониторов, обеспечивающим нужную скорость обработки изображений быстродействием процессора).
В режиме клиент—сервер выделяют две разновидности структуры: одноуровневую и многоуровневую. При использовании режима «толстого» клиента (одноуровневая структура) клиентские приложения находятся непосредственно на машинах пользователей, либо частично на сервере в виде системы хранимых процедур. Сложность клиентской части порой требует ее администрирования. Использование системы хранимых процедур в значительной мере снижает нагрузку на сеть. При использовании «тонкого» клиента (многоуровневая структура) приложения пользователей лежат и выполняются на отдельном мощном сервере (сервере приложений, который может быть и на одном компьютере с сервером БД), что в значительной мере снижает требования к пользовательским машинам.
Требования и рекомендации к «новым» методам и инструментам проектирования БД:
Об исключении избыточности в данных: требование однократного ввода данных в БД сохраняется как разумное и прежде всего для защиты от возникновения противоречий (нарушении логической целостности) при актуализации хранимых данных. Однако в условиях глобального информационного пространства и компонентного проектирования контекст этих требований должен быть пересмотрен. Несомненно, в операционных БД рационально планировать «острова» нормализованных и, в классическом смысле, безызбыточных кластеров отношений или объектов. Эти «острова» чаще всего и будут являться давно известными предметными БД. Кроме того, заранее не регламентированный поток информации из Internet в корпоративную БД потребует разработки или увеличения возможностей «процедур отождествления» экземпляров информационных структур, т. е. выяснения того, что эти экземпляры описывают один и тот же предмет реального мира.
При этом, с точки зрения прагматики, создание базы данных — это, по существу, попытка найти компромисс сразу по нескольким направлениям и сочетаниям нескольких взаимообратных факторов (с точки зрения их влияния на показатель общей эффективности системы), в том числе следующих:э
- 1) эффективность — простота;
- 2) скорость выборки — стоимость (сложность) аппаратных средств;
- 3) скорость выборки — сложность процедур доступа;
- 4) плотность данных — время доступа и сложность процедур;
- 5) независимость данных — производительность;
- 6) гибкость средств поиска — избыточность данных;
- 7) гибкость поиска — скорость поиска;
- 8) сложность процедур доступа — простота обслуживания.
- Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / Под ред. npоф. А. Д. Хомоненко. — 6-е изд., доп. - СПб.: КОРОНА-Век, 2009. - 736 с.
- Советов Б. Я. Базы данных: теория и практика : учебник для бакалавров / Б. Я. Советов, В. В. Цехановский, В. Д. Чертовской. — 2-е изд. — М. : Издательство Юрайт, 2014. — 463 с. — Серия : Бакалавр. Базовый курс.
- Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. — М.: ФОРУМ: ИНФРА-М, 2006. — 352 с: ил. — (Профессиональное образование).