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

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

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

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

Ø Защита сервера – приоритетная задача.

Ø Для повышения производительности требуется вначале произвести на компонентах сервера специальные процедуры (например, индексирование или нормализацию таблиц).

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

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

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

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

Ø Какие требуются объекты базы данных? Иными словами, что будет представлять собой модель данных?

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

Ø Какие таблицы или представления будут основными? Почти в каждой модели данных некоторые таблицы более важны, нежели другие. Следовательно, необходимо рассмотреть весьма вероятное событие, когда в сети клиент/сервер к этой таблице попытается обратиться много пользователей. Кроме того, необходимо предусмотреть меры защиты важных данных от разрушительных изменений (например, модификаций ключевых значений в отношении один-к-многим), а также от несанкционированного доступа. Для реализации этих мер имеется широкий диапазон средств – от определения пользовательских логических структур, ограничивающих доступ к объектам базы данных, до написания триггеров, которые при некоторых условиях предотвращают проведение изменений в базе данных.

Ø Какие бизнес-правила целесообразно установить на сервере? Здесь необходимо балансировать между нежелательностью перегрузки сервера работой по обслуживанию каждого бизнес-правила и необходимостью установки на сервере важных ограничений, которые должны гарантировать целостность и согласованность данных приложений всех клиентов.