Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Базы данных

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

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

Создание собственно БД предполагает использование языка программирования 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 данной работы.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

Популярные страницы