Процедура проектирования баз данных

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

Создание собственно БД предполагает использование языка программирования SQL или QBE для:

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

В заполнении таблиц выделяют: начальное заполнение — для тестовой проверки работы БД; рабочее заполнение. Заполнение возможно осуществлять вручную (удобнее всего для небольших по объему таблиц и при начальном заполнении) или программно (при заимствовании данных из других электронных источников).

Ручное заполнение возможно двумя способами:

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

Интерфейс пользователя

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

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

• 1. Ориентация на требования пользователя (а не на умение разработчика) — User_centred Design.
• 2. Согласованность (использование однозначных команд в рабочей среде).
• 3. Наличие обратной связи от компьютера (сигнал о восприятии команды).
• 4. Простота интерфейса — предоставление только тех его элементов управления, которые нужны на данном шаге сеанса работы с программным продуктом. Под сеансом (сессией) понимается интервал времени от запуска продукта до выхода из него.
• 5. Гибкость интерфейса — способность учитывать уровень подготовки пользователя.
• 6. Учет эстетических требований, в которые включаются время освоения интерфейса, время решения задачи, субъективная удовлетворенность удобством интерфейса.
• 7. Учет традиций предметной области.
• 8. Итерационный характер разработки интерфейса с учетом предпочтений пользователя.
• 9. Учет возможностей программных и аппаратных средств.
• 10. Возможность учета психологических характеристик пользователя: левое полушарие мозга лучше воспринимает текст, правое — образы, изображения.
• 11. Учет возможностей упрощения программирования.
• 12. Малое время отклика компьютера: если интервал от запроса до ответа компьютера превышает 20 с, систему не считают интерактивной.

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

Основой интерфейса пользователя является система элементов управления совместно с формами и отчетами.

В качестве синхронизирующего объекта в интерфейсе пользователя используют либо (головное) меню, либо кнопочную форму.

Алгоритм приложения

В традиционном подходе формируется алгоритм прямого преобразования данных исходных таблиц в выходные документы. В качестве выходных документов (таблиц) выступают запросы и отчеты. Запросы формируются с помощью языка программирования SQL или QBE. Отчеты являются фактически запросами, снабженными дополнительными пояснениями. Отчеты могут реализоваться с помощью различных конструкторов (при фактически ручном создании) или с помощью мастеров (в полуавтоматическом режиме).

Алгоритмы приложения в современном подходе отличаются от алгоритмов приложения более сложными вычислениями с возможным формированием промежуточных объектов. Алгоритм приложения может быть написан на различных языках программирования — например, Visual Basic for Applications (VBA), Object Pascal, SQL. В последнем случае он выполняется в виде хранимых процедур, генераторов, триггеров.

В заключение следует отметить, что процесс проектирования итеративен: могут постоянно изменяться требования в ТЗ, составляющие проектирования и реализации БД.

Процессы проектирования и реализации рассмотрим на двух примерах — «Учебный процесс» и «Прием на работу», сжатое описание которых приведено в примерах 2.1 и 2.2.

Реализация описанных в примерах баз данных проводится на СУБД Access и InterBase (в рамках программного продукта Delphi).

Многочисленным возможностям указанных СУБД посвящены специальные отдельные публикации [27−36, 41]. Освоение возможностей, как показал опыт, целесообразно проводить в два этапа:

• 1) рассмотрение основной ветви технологии реализации на конкретном примере (БД) с использованием ограниченного круга возможностей СУБД;
• 2) детальное освоение — по подробным описаниям [27−36, 41] - названных СУБД при учете их многочисленных частных возможностей.

Работы на втором этапе после тщательного изучения технологии на первом этапе, как показывает практика, не вызывает особых затруднений. В то же время описание многочисленных частных процедур второго этапа, как явствует из работ [17−36], занимает объем, превышающий настоящую публикацию. В связи с этим в данной работе осветим только первый этап.

Процедура создания хранилищ данных только начала формироваться. В настоящее время выделились два варианта:

• • полный, описанный в гл. 2;
• • «усеченный», заключающийся в периодической передаче в архивные таблицы данных из оперативных таблиц. Связи между архивными таблицами чаще всего отсутствуют.

Второй вариант приведен в работе [32] и рассмотрен в § 15.4 данной работы.