Time is money!

Филатов Д.Н.
softdeveloper@mail.ru

Степень нормализации схемы базы данных (БД) в значительной мере оказывает влияние на реализацию клиента СУБД. По меньшей мере, клиент СУБД должен содержать в себе формы для ввода и редактирования справочников, не говоря о формах для ввода информации в накопительные таблицы. Зачастую, чем выше степень нормализации БД, тем сложнее интерфейс клиента СУБД. Предлагается упростить разработку клиентов СУБД за счет применения универсального класса.
Практическая реализация описываемой методики проводилась с применением среды разработки приложений Borland Delphi. В качестве целевого сервера СУБД применялась ознакомительная версия Oracle.
Предком для универсального класса (УК) был выбран класс-наследник TDataSet, имеющий средства для доступа к Oracle через механизм доступа к данным ADO - TADODataSet. Вызов формы для редактирования осуществляется выполнением метода Execute. Для представления УК в качестве визуального компонента непосредственно на форме приложения был применен прием встраивания компонентов - докинг. УК (TExData) имеет свойство DockInto:TWinControl, которое может ссылаться на любого потомка TWinControl, в который при старте приложения будет встроена форма ввода информации УК. Если данное свойство пусто, вызов формы ввода информации УК может быть осуществлен только вызовом метода Execute.

Рис. 1. Упрощенная схема организации классов TExData и TLink.

Непосредственно на самой форме ввода информации размещаются несколько типовых наиболее часто применяемых компонентов: навигатор записи, кнопки "Ок", "Отмена", "Commit", "Rollback" и т.п. Совершенно очевидно, что для большинства задач этих компонентов будет достаточно, однако форма ввода данных УК может быть существенно расширена за счет применения докинга (технология взаимного встраивания визуальных компонентов). Любой наследник TWinControl может быть встроен в форму ввода данных (свойство InternalControl). Для позиционирования встраиваемого компонента служит свойство TargetAlignment, которое определяет, в каком месте формы и в каком виде будет отображаться встраиваемый компонент. На самом встраиваемом компоненте могут быть размещены дополнительные элементы управления, а обработчики событий этих элементов управления будут содержаться в основной программе. У пользователя создается впечатление, что форма полностью монолитна, между тем разработчик получает широкие возможности по многократному использованию кода.
Последовательность действий программиста при разработке новой формы сводится к следующему.
1. По числу справочников СУБД и форм для ввода данных создаются объекты - экземпляры УК (ЭУК).
2. В каждом ОУК определяем базовый запрос SQL на выборку, который определяет выборку таблиц справочников целиком, а при наличии внешних связей один-ко-многим и пр. с другими таблицами - выборку значений внешних ключей из этих таблиц.
3. В коллекции настроек связей УК создаем экземпляры членов коллекции - объектов связей (ОС) TLink, количество которых равно количеству внешних ссылок по внешним связям. В свойствах каждого ОС указываем имя связанного и настроенного УК, карту связей полей, тип реакции УК на ввод нового значения, параметризированные значения полей по умолчанию.
Карта связей полей (мэппинг) представляет собой хэш-таблицу вида Поле-источник=Поле-приемник. Данная карта связей определяет направление информации в разрезе полей источник-приемник при редактировании и вводе данных из связанного ЭУК. Для полей, являющихся значениями внешних ключей карта связей также указывается с целью отображения информации в форме ввода при добавлении и изменении записей, однако в СУБД записываются только значения внешнего ключа.
4. В настройках интерфейса ЭУК определяем внешний вид пользовательского интерфейса формы данных, указываем русские наименования заголовков полей выборки и т.п.
Развивая функциональность базового УК, включая в его состав новые возможности (экспорт выборки в Excel, например), разработчик достигает значительного роста функциональности всех своих приложений, построенных на базе УК. В некотором смысле УК представляет собой подобие CASE-среды разработки СУБД с той разницей, что CASE-среда оперирует сущностями на уровне отдельных таблиц, а УК в своем базовом запросе на выборку, как правило, содержит результат объединения нескольких таблиц.
Опыт практического применения описанной методики показал высокую эффективность использования УК при разработке сложных клиентов СУБД. По своей сути программирование клиентов СУБД перешло из плоскости рутинного программирования десятков однотипных форм к творческому проектированию бизнес-логики. Разработчик, определив запрос SQL, заголовки столбцов выборки и связи между ЭУК, получает унифицированную форму ввода и обработки информации без необходимости достаточно трудоемкого кодирования ее функционала.

Перепечатка без ссылки на автора статьи запрещена.