Если проектирование начинается с сервера, имеется возможность сформировать эффективную модель данных, отражающую информацию из реальной жизни. Объектом реальной жизни может быть любой объект (например, данные служащего, транзакция бухгалтерской книги, позиция инвентарной ведомости и т.д.), который требуется описать в одной или больше таблиц.
Начиная проектирование с сервера базы данных, необходимо ответить на следующие вопросы:
- Какие требуются объекты базы данных? Иными словами, что будет представлять собой модель данных?
- Как следует оптимизировать структуру данных с точки зрения повышения производительности их обработки?
- Какие таблицы или представления будут основными? Почти в каждой модели данных некоторые таблицы более важны, нежели другие. Следовательно, необходимо рассмотреть весьма вероятное событие, когда в сети клиент/сервер к этой таблице попытается обратиться много пользователей. Кроме того, необходимо предусмотреть меры защиты важных данных от разрушительных изменений (например, модификаций ключевых значений в отношении один-к-многим), а также от несанкционированного доступа. Для реализации этих мер имеется широкий диапазон средств – от определения пользовательских логических структур, ограничивающих доступ к объектам базы данных, до написания триггеров, которые при некоторых условиях предотвращают проведение изменений в базе данных.
- Какие бизнес-правила целесообразно установить на сервере? Здесь необходимо балансировать между нежелательностью перегрузки сервера работой по обслуживанию каждого бизнес-правила и необходимостью установки на сервере важных ограничений, которые должны гарантировать целостность и согласованность данных приложений всех клиентов.
Как проектировать пользовательские классы и библиотеки
Прежде, чем приступать к разработке приложения, необходимо рассмотреть возможность неоднократного использования в ходе разработки некоторых объектов или наборов объектов. Вот некоторые примеры таких объектов:
- Эмблема компании, которая присутствует на многих формах и отчетах.
- Набор средств управления, используемых для навигации по записям.
- Набор элементов управления, используемых для фильтрования и сортировки записей.
- Группа переключателей, используемых для обеспечения стандартного набора опций в нескольких формах
- Ряд текстовых полей, выводящих в нескольких формах информацию заказчика, продавца или компании.
Создавая эти объекты как пользовательские классы, сохраненные в приложении или в библиотеке, разработчик получает следующие преимущества:
- После того, как объекты созданы, добавление их к форме может выполняться простой операцией drag-and-drop.
- В Oracle Power Objects экземпляры пользовательского класса или объекты библиотеки наследуют свойства и методы определения исходного класса. Точно также экземпляры наследуют изменения, проводимые в этих определениях. Следовательно, изменение часто используемых объектов приложения выполняется намного быстрее, если они создаются как экземпляры. При этом, чтобы провести изменение по всем экземплярам, требуется изменить лишь определение пользовательского класса или объекта библиотеки.
Решение по созданию объекта приложения многократного использования как пользовательского класса принимается по результатам ответа на вопрос: этот объект будет использоваться один раз только в данном приложении, или, возможно, он потребуется в нескольких приложениях или несколько раз в одном приложении?
- Если предполагается использовать объект в нескольких приложениях, целесообразно создать его как объект библиотеки (или как объект-библиотеку). Когда потребуется изменить объект, он выделяется в собственную библиотеку, подобную библиотеке динамической компоновке (DLL) в среде Windows.
- Если планируется использовать объект только в одном приложении, можно создать его как пользовательский класс, При хранении пользовательского класса в приложении уменьшается количество поддерживаемых объектов-файлов.
- Oracle Power Objects позволяет создавать как объекты библиотеки пользовательские классы и растровые рисунки. Пользовательские классы – наиболее применяемый тип объектов библиотеки, так как они обеспечивают все функциональные возможности как контейнеров, так и элементов управления.
Суммируя вышеизложенное:
- База данных содержит объекты, предназначенные для хранения и организации информации.
- Сеанс обеспечивает доступ к базе данных, а также к коллекции объектов базы данных, определенных логической структурой (схемой) пользователя базы данных.
- Приложения внешнего интерфейса выполняют запросы базы данных, заполняя информацией наборы записей.
Наборы записей обычно связываются с объектами-контейнерами, которые непосредственно предоставляют пользователю доступ к данным, хранимым в базе данных.
Несмотря на то, что Oracle Power Objects обеспечивает обширный набор средств для разработки любых видов приложений, этот инструмент ориентирован и предназначен, в первую очередь, для формирования приложений базы данных в среде клиент/сервер. Используя один и тот же внешний интерфейс в системе клиента, можно выбрать любую систему управления базами данных по критериям защиты, эффективности, масштабируемости и другим важным функциям. Кроме того, Oracle Power Objects позволяет устанавливать и поддерживать специфические требования к данным средствами как приложения-клиента, так и сервера базы данных.
OPO - новый продукт на рынке средств разработки приложений клиент/сервер. У него нет за спиной богатой истории развития и как чисто инструментального языка (Visual Basic, Delphi) и как инструмента создания приложений для системы клиент/сервер (Forms). Первую версию скорее можно воспринимать как заявку на место на рынке, как демонстрацию новых идей. Если будет улучшен пользовательский интерфейс Среды разработки, введена полная поддержка OLE и особенно OLE Automation, будут созданы драйверы для других источников данных, при разработке можно будет использовать репозитарий приложения, то OPO действительно может стать весьма интересным продуктом.
1. Г.Анзер: «Oracle Power Objects», Мосва, АБФ, 1997
2. www.oraclub.trecom.tomsk.su/articles/mir-ora/program/23.htm