Базы данных

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

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

      Имена объектов  базы  данных  должны  отвечать  правилам   именования

объектов  для базы данных, в которой они  сохранены. Эти правила различны  для разных баз данных. 
 
 
 
 
 
 
 

Среда разработки 

     Среда разработки OPO внешне напоминает ставшую уже стандартной среду Visual Basic. Верхний уровень иерархии объектов OPO - это объект ы File, изображенных в виде иконок на основном окне среды разработки и которых может быть три типа :

      Приложения (Application)

      Объекты Базы Данных (Database session)

      Библиотеки (Library)

      Каждая такая иконка может быть раскрыта в окно, содержащее объекты нижнего уровня иерархии. Копирование объектов между однотипными группами осуществляется простым переносом иконок . При создании и редактировании объектов появляется инструментальная линейка и окно редактирования свойств и методов. В процессе разработке можно запускать на выполнение как все приложение, так и отдельные экраны (формы) и отчеты. Большую помощь при отладке может оказать отладчик, функционально аналогичный отладчику в Visual Basic. Важно отметить возможность работать с объектами Базы Данных (таблицами, представлениями, индексами и т.д.) непосредственно из среды разработки OPO. Вместе с тем, представление объектов в виде иконок и раскрывающихся окон удобно только при весьма небольшом их количестве. Когда число используемых объектов превышает несколько десятков , становиться очень сложно ориентироваться среди них и разбираться среди множества раскрытых и мешающих друг другу окон. Реализованный в Forms 4.5 Навигатор Объектов [3] заметно более нагляден и удобен. Большое число иконок в окне, а число объектов (таблиц, представлений , индексов и последовательностей) в даже небольшой БД превышает несколько сотен, в Windows 3.1/3.11 вызывает истощение системных ресурсов и приводит к ее краху. 

Структура приложения 

      Приложение можно разделить на четыре структурные части : Application и RecordSet представляют обращенную к пользователю часть

приложения (Front End), Session и Database являются частью выполняющегося на сервере приложения (Back End). В зависимости от задач, требований к сетевому трафику и характеристик аппаратуры необходимо распределять логику работу приложения между этими частями. Обработку транзакций и поддержку целостности данных можно осуществлять во всех структурных частях приложения.

     Основной частью (и видимой пользователю) частью приложения является форма или экран (Form). При создания экранов можно применять все стандартные элементы Windows приложений - поля и метки, различного рода кнопки, списки и т.д. Экраны могут содержать вложенные экраны. 
 
 
 

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

Обработка транзакций 

      Любая транзакция должна пройти  через  несколько  уровней,  каждый  из

которых играет свою роль в управлении обработкой транзакций.

   1. Контейнеры. Контейнер – элемент  интерфейса, через который пользователь инициирует запросы  и  изменения  набора  записей.  После  добавления, удаления или изменения записи пользователь перед закрытием контейнера должен  фиксировать или аннулировать  транзакцию  (обычно,   нажимая кнопку, предназначенную для этой цели – чаще всего, это кнопки  ОК  и  Отмена (Cancel)). Кроме  того,  здесь  определяют  устанавливаемые  на уровне  клиента  бизнес-правила,  ограничивающие  транзакции,  которые может  инициировать  пользователь.  Если   система   должна   сообщить  пользователю   относительно   результатов   предпринятой   транзакции, информация появляется здесь же, в интерфейсе пользователя.

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

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

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

      Следовательно,   при   управлении   транзакциями   внутри   приложения

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

Подход  к разработке, реализуемый  в Oracle Power Objects 

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

объемов работы.

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

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

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

      С  другой  стороны,   высококачественные   инструментальные   средства

клиент/сервер  часто  требуют,  чтобы  их  проектирование  было  начато   с

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

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

Если  начать с клиента 

      Обычно, с разработки внешнего  интерфейса начинают, когда…

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

        
 
 
 

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

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

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

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

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

            Объекты интерфейса и их  связанные   таблицы  или  представления можно также разрабатывать параллельно, так как таблицы и представления

структурно  часто дублируют формы и  отчеты,  в  которых  выводятся  их

записи. 

Если  вначале разрабатывается  внешний интерфейс, следует ответить на

следующие вопросы: 

        > Какими  будут  главные  формы,  которые  пользователь  увидит  на экране? Они будут, вероятно  первыми  объектами,  которые  должны быть  спроектированы,  наряду  с  их  связанными  таблицами   или представлениями.

        >  Какая  модель  последовательности  действий  будет  заложена   в

приложение? Иными словами, следует тщательно  продумать, как легко пользователь сможет вводить данные, осуществлять навигацию  между формами и выполнять  другие  операции  внутри  приложения.  Кроме

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

        
 
 

       > Какие объекты должны быть определены вне приложения Oracle  Power Objects  и затем импортированы?  Например,   если   планируется добавлять растровые образы  или другие  OLE-объекты,  возможно, вначале  придется  разработать   некоторые   из   этих   ресурсов приложения.

        > Где лучше и как  лучше   установить  ограничения?  Например,  если требуется гарантировать, чтобы транзакция, введенная в приложении регистрации заказов, не содержала значений, превышающих некоторый объем,  возможно,  будет лучше установить  это ограничение на клиенте через код Oracle Basic, а не на  сервере через триггер. Для этого потребуется добавить необходимый код Oracle  Basic, который будет прерывать транзакцию  до  ее  фиксации,  если  она превышает установленный объем заказа.