Программные продукты и системы

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

Для примера рассмотрим таблицу учета материалов[1]:

Рис.1. Базовая таблица учета материалов

Очевидно, что формат этой части таблицы практически не зависит от вида материалов.

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

Например при учете компьютеров:

Если необходимо вести учет жевательной резинки, то таблица примет примерно следующий вид:

Таким образом, поля таблицы можно разбить на две группы:

  Постоянную часть – условно независимую[2] от типа предприятия и от хранящихся в ней данных.

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

Поле, значение которое задает состав полей, назовем определяющим полем.

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

*        В большинстве систем управления БД количество полей ограничено, межу тем как количество аналитических параметров, которые необходимо учитывать, может быть велико.

*        Если даже удастся разместить большое число параметров в плоскую таблицу, то коэффициент заполнения записей такой таблицы будет крайне низким, что нерационально скажется на эффективности использования устройств долговременного хранения информации (жестких дисков) и на скорости отбора информации.

*        Состав параметров от одного предприятия, использующего этот АРМ, к другому сильно изменяется. Даже в пределах одного предприятия изменение номенклатуры влечет изменение состава параметров, что приводит к необходимости постоянной модификации таблицы.

*        Удобство заполнения таблиц с большим числом колонок весьма проблематично.

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

Идеальный конечный вариант

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

Идеальным вариантом будем считать такое решение, которое наиболее полно удовлетворит потребности следующих категорий пользователей.

*        Конечного пользователя

Удобство ввода информации и возможности динамической настройки системы под свои нужды.

*        Программиста

Наличие полного комплекта программных средств и управляющих структур, необходимых для работы по технологии дополнительных параметров.

*        Системного администратора сети и БД

Непритязательность системы к количеству ограниченных системных ресурсов, таких как дисковое пространство, количество обращений к БД, объем сетевого трафика.

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

Важные критерии удобства следующие:

*        Обозримость:

*        дефрагментация большого объема информации на части, облегчающие целостность восприятия;

*        фильтрация только нужной информации.

*        Понятность:

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

· Удобство ввода и редактирования данных:

· возможность быстрого перехода от одного редактируемого поля к другому;

· возможность организации поиска необходимой информации из внешних (по отношению к редактируемой) таблиц;

· наличие контроля за правильностью введенной информации.

Игнорируя на первом этапе проблемы, связанные с физической и программной организацией таблиц с большим числом полей, пользователь может считать что он имеет дело с одной таблицей, обладающей следующими свойствами:

¨ Количество полей в таблице не ограничено.

¨ Пользователь может при необходимости динамически (в процессе работы) менять количество полей таблицы.

¨ При вводе информации должно быть доступно только такое множество полей, которое определено значениями, содержащимися в определяющих полях таблицы (в приведенных выше примерах таким полем является номенклатурный № материала).

 Можно предложить достаточно большое количество способов отображения информации на экране компьютера, но применительно к данной задачи наиболее оптимальными являются два: в виде таблицы и списком.

Независимо от способа представления можно ввести следующие правила отображения полей записи.

1. В момент создания новой записи пользователю видна только постоянная часть таблицы.

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

1.2. Пользователь может заполнить только часть полей полного множества (на рисунке 2 поле «Вкладыш» не заполнено).

2.При переходе от записи к записи пользователь видит постоянно изменяющийся от записи к записи состав полей.

2.1. Если определяющее поле заполнено, то пользователь видит не полное множество, а подмножество только заполненных полей

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

Представление в виде таблицы

При данном способе отображения информации таблица для пользователя представляется в виде таблицы с записями переменной длины (рис. 4), состав полей меняется.

Рис. 4. Отображение таблицы с дополнительными параметрами таблицей

Шапка такой таблицы постоянно изменяет состав полей переменной части таблицы.

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

При данном способе представления информации отображение таблицы производится двумя частями (рис. 5).

Первая часть - основная таблица. Это обычная таблица с неизменяемыми полями, а вторая - таблица дополнительных параметров, содержимое которой перерисовывается от записи к записи.

Программист. Его основными функциями являются:

· написание запросов к БД (в том числе хранимые процедуры):

Þ     создание на основе запросов промежуточных таблиц;

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

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

Работа с современными БД производится на базе SQL-серверов, доступ к данным при этом осуществляется при помощи SQL-запросов. Язык SQL стандартизирован и не предназначен для обработки таблиц с переменным числом и составом полей. И само понятие таблиц с записями переменной длины в реляционных БД не существует.

 Рис. 5. Отображение таблицы с дополнительными параметрами списком

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

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

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

Рис. 6. Отображение таблицы с дополнительными параметрами с точки зрения программиста

Как видно из рисунка, содержание формат переменной части таблицы определяется информацией таблицы «Перечень доп. параметров». Для работы также необходимо, чтобы таблица содержала уникальный идентификатор записи.

Анализ потребностей программиста при организации запросов подразделяет их на два варианта:

1. Полная выборка данных заполненных полей переменной части таблицы.

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

Результат выборки информации по варианту 1 представлен на рисунке 7.

Рис. 7. Пример результата выполнения запроса к таблице с ополнительными параметрами

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

Результат выборки по варианту 2 ничем не отличается от обычного запроса, кроме того факта, что подобный запрос не может быть обработан при помощи стандартного SQL-запроса. Между тем простой выход из положения существует и не единственный. Самый простой вариант заключается в использовании механизма хранимых процедур[3] для получения записи необходимого вида. Для этого определим хранимую процедуру ReadRecord со следующими параметрами.

ReadRecord

(

ID integer,         /*Идентификатор записи */

NamePar1 char(25),          /*Имя параметра 1 */

NamePar2 char(25),

...

NameParN char(25) /*Имя параметра N */

)

RETURNS

(

Field1 varchar(100), /*Содержимое поля параметра 1*/

Field2 varchar(100),

...

FieldN varchar(100)/*Содержимое поля параметра N*/

);

Рис. 8. Процедура получения записи из полей дополнительных параметров необходимого вида

Данная процедура возвращает информацию из переменной части таблицы в полях Field1..FieldN в последовательности, заданной именами параметров NamePar1..NameParN. Незадействованные поля могут быть заданы через передачу параметра типа NULL.

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

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

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

ReadComputer

(

<параметры условий выборки>

)

RETURNS

(

NN     integer,

Amnt       float,

Price      float,

ProcType   char(10),

Hdd        float,

Ram        integer

)

AS

declare variable ID integer;

declare variable Param1 varchar(100);

declare variable Param2 varchar(100);

declare variable Param3 varchar(100);

BEGIN

FOR SELECT ID, NN, Amnt, Price

       FROM Material

[WHERE,ORDER BY,GROUP BY <условия выборки>]

       INTO :ID, :NN, :Amnt, :Price

DO begin

 /*Вызов хранимой процедуры, возвращающей 3 поля доп. параметров*/

EXECUTE PROCEDURE ReadRecord3( :ID)

RETURNING_VALUES(:Param1,:Param2,:Param3);

 /*Чтение результата с преобразованием типа (при необходимости)*/

ProcType = Param1;

Hdd = Param2;

Ram = Param3;

 SUSPEND;

end

END;

Рис. 9. Пример процедуры получения ограниченной по числу полей выборки

Если условия выборки обеспечивают отбор записей, содержащих информацию о компьютерах, то мы получим таблицу с полностью заполненными полями. В противном случае большая часть записей в полях переменной части таблицы будет содержать значение «NULL».

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

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

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

К сожалению, предложенные подходы к решению первоначально сформулированной проблемы не отвечаю многим практическим потребностям и не решают ряд важных вопросов:

Þ Как быть, если число определяющих полей больше чем одно?

Þ Каким образом значение поля определяет состав дополнительных параметров?

Þ Каким образом сохранять поля различного типа, в том числе длинные поля?

Þ Каким образом будут отображаться поля различного вида (под видом понимается функциональное назначение полей)?

Эти проблемы предполагается рассмотреть в последующих номерах журнала.

Список литературы

1. Литвинов Ю.С., Масюков В.А. - Комплекс информационных технологий для разработки производственно-управляющих систем масштаба предприятия // Программные продукты и системы. - 1996. - № 2. - C.40-43.