Участие администратора БД в разработке приложения

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

— наделять администратора БД функциями управления разработкой приложения;

— создавать управляемые приложения – нужного размера и правильно организованные;

— реализовывать ограничения целостности БД максимально средствами СУБД;

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

— определять таблицы и индексы, которые чаще всего будут использоваться приложением;

— обнаруживать и исправлять недостатки в SQL—конструкциях, чтобы избежать их воздействия на производительность системы;

— четко определять права доступа пользователей и стремиться максимально реализовывать их средствами СУБД;

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

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

Виды функций приложений БД

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

Основная функция приложения БД – обработка данных. Для баз данных определены четыре основные функции обработки: добавление и обновление данных, чтение и удаление.

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

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

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

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

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

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

Функция чтения в БД реализуется, как правило, посредством SQL—запроса. АБД должен требовать, чтобы запросы проектировались с учетом их производительности: правильно использовались операции соединения (естественное, внешнее левое, внешнее правое); подзапросы, индексы и другое. При анализе плана выполнения запроса АБД может сделать соответствующие выводы и порекомендовать разработчику запроса изменить его структуру, спроектировать дополнительные индексы. Оптимальным является вариант совместного проектирования запросов администратором БД и прикладным программистом с учетом всех требований, накладываемых СУБД, приложением, вычислительной средой, предметной областью.

Важным для автоматизированной информационной системы является адекватное, с точки зрения конечного пользователя, представление данных на интерфейсных формах ввода/ вывода, в различных документах и отчетах, формируемых прикладной программой. Данные, взятые из БД, могут иметь много различных форматов – каждый конечный пользователь определяет свой формат. Востребованным являются форматы MS Word, Excel, форматы интернет—страниц.

В функции приложения БД входит и функция реализации контроля доступа к данным. В приложении, разрабатываемом для работы с БД, должна быть реализована процедура авторизация пользователя БД. Механизмы идентификации реализуют, как правило, средствами приложения, а аутентификации – средствами СУБД. Например, в приложении реализован интерфейс ввода имени и пароля пользователя, обработка сообщения об отказе в доступе. В механизме аутентификации используют, как правило, такие объекты БД, как представления и роли. В разрабатываемом приложении проектируется настройка и обработка результатов идентификации и запуск механизма аутентификации посредством использования специальных визуальных компонентов, реализации логики обработки соответствующих событий. Если разрабатывается одно, но многопользовательское приложение, механизм аутентификации может быть реализован частично через элементы интерфейса приложения. Проектируется разделение доступа пользователей (в зависимости от их привилегий) к соответствующим визуальным компонентам форм (меню, кнопки и другое) приложения, при этом разграничивается выполнение тех или иных функций приложения. Например, один пользователь может выполнять все функции приложения, другой – только доступные в заданном пункте меню.

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