АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Цель: Описание структуры серверной части системы Alfa. Систематизация серверной части. Обеспечение управляемости и контроля над серверной частью системы

Читайте также:
  1. Aufgabe 4. Везде ли нужна частица “zu”?
  2. I частина (5 балів)
  3. I частина (5 балів)
  4. I. 1.1. Пример разработки модели задачи технического контроля
  5. I. Необходимые документы для участия в Конкурсе
  6. I. Оценка изменения величины и структуры имущества предприятия в увязке с источниками финансирования.
  7. I. Размер базовой части трудовой пенсии по старости.
  8. I. Разработка структуры базы данных.
  9. I. Расчет накопительной части трудовой пенсии.
  10. I. Расчет размера страховой части трудовой пенсии.
  11. I. Саморазрушение Структуры
  12. I. Формирование системы военной психологии в России.

Стандарт 5. Архитектура серверной части.

 

Стандарт 5. Архитектура серверной части. 1

Основные положения. 2

Схема серверной архитектуры. 4

Структура интерфейсного типа таблицы. 5

Управление приложением через контекст. 5


Основные положения

 

  1. Управление транзакциями. Используются длинные транзакции.
  2. Используется технология тонкий клиент. Т.е. вся обработка данных сосредоточена на сервере БД.
  3. На основе реляционной СУБД Oracle построено объектное хранилище данных на основе дерева пользовательских классов (в дальнейшем просто классов). Объекты системы являются экземплярами классов.
  4. Объектное хранилище данных построено на основе таблиц метамодели. Объекты хранятся в универсальной структуре хранения (УСХ), заложенной в метамодели, или в собственных индивидуальных структурах, настроенных на уровне их классов.
  5. Система является многоязыковой, все именования описания дерева классов и метамодели создаются при помощи «понятий». Понятию принадлежит определенное пространство текстовых представлений. Например для понятия «валюта» существуют текстовые представления «валюты», «введите валюту» и т.п. Каждое текстовое представление может вводиться в различных языках, зарегистрированных в системе. Сами объекты пользовательских классов не являются многоязыковыми, они вводятся на определенном языке.
  6. Любая таблица метамодели содержит уникальное поле Id – первичный ключ. Обеспечивается уникальность Id только внутри таблицы. Для этого к таблице создается Sequence.
  7. Доступ к низкоуровневому хранилищу информации (таблицам метамодели), хранящему описание дерева классов, понятия, УСХ и т.п. осуществляется через интерфейсные API-типы. Рисунок 1.
  8. Набор таблиц метамодели объединяется в бизнес-объекты (БО) метамодели. Существование записи в одной из таблиц БО не имеет значения без соответствующих записей в других таблицах БО.
  9. DPI-типы для каждой таблицы метамодели создаются автоматически, из Er-win. Этот тип содержит набор стандартных статических функций и процедур, обеспечивающих взаимодействие с указанной таблицей. Редактирование DPI-типа запрещено.
  10. API-тип создается для каждой таблицы метамодели, он наследуется от соответствующего DPI-типа. В нем происходит переопределение необходимых методов DPI-типа и определение новых.
  11. Любое обращение из внешней среды на изменение к таблицам метамодели запрещено. Операции INSERT, UPDATE, DELETE осуществляются через методы API-типа. Обращение к методам DPI-типа разрешено только в API-типе для той же таблицы метамодели.
  12. В некоторых случаях реализации серверной логики на уровне метамодели, при необходимости осуществления массированных изменений, разрешено прямое обращение к таблицам метамодели через INSERT, UPDATE, DELETE.
  13. Информация о дереве классов хранится в метамодели. Классы наследуются друг от друга. Класс имеет набор атрибутов, состоящий из унаследованных от классов-предков атрибутов, перекрытых атрибутов и собственных атрибутов. Перекрытие атрибута осуществляется путем создания в классе-наследнике одноименного атрибута.
  14. Каждый класс содержит весь перечень собственных экземпляров объектов, а также все объекты классов-потомков.
  15. В системе реализовано множественное наследование на уровне объекта. Один и тот же объект может одновременно быть экземпляром нескольких классов. Причем некоторые из атрибутов, определенных для разных классов, которым принадлежит объект, могут иметь синхронизируемые значения.
  16. Для внешней среды пользовательский класс должен быть представим в табличном виде, для осуществления выборок его данных запросами SELECT. Для этого, для каждого класса создается вид с именем: CLS_<имя класса>.
  17. Для каждого класса автоматически создается DPI-тип, содержащий стандартный набор статических процедур и функций, реализующих интерфейс данного класса. DPI-тип не редактируется.
  18. API-тип создается для каждого класса, он наследуется от соответствующего DPI-типа. В нем происходит переопределение необходимых методов DPI-типа и определение новых.
  19. При создании класса-наследника, его DPI-тип наследуется от API-типа класса-предка. Тем самым осуществляется наследование методов от класса к классу.
  20. Любое обращение на выборку экземпляров класса осуществляется через его вид, а любое обращение на изменение его объектов – через API-тип класса.
  21. На конкретных проектах внесение изменений осуществляется путем создания собственных наследников от существующего дерева классов и перекрытия или определения серверных методов.
  22. Изменение API-типа класса, от которого существуют наследники, осуществляется регламентным образом, описанным в Стандарте 6.
  23. Реализация бизнес логики в триггерах запрещена.
  24. Отображение данных метамодели или пользовательских классов на клиентское приложение осуществляется при помощи выборок. Выборка представляет собой набор операций, доставляющих и изменяющих данные на клиенте. Выборки хранятся на сервере.
  25. Выборка имеет набор атрибутов, свойства которых определяют способы вывода атрибута на клиентском приложении.
  26. Выборки наследуются друг от друга. В выборке наследнике автоматически появляется весь набор операций и атрибутов, определенных в предке. В выборке наследнике эти атрибуты и операции могут быть переопределены, а так же могут быть созданы новые.
  27. Для каждого класса создается три выборки по умолчанию: одна для редактирования класса в табличной форме, две другие наследуются от нее и предназначены для редактирования класса в карточной форме (одна выборка для вызова карточки из табличной формы, другая выборка для самой карточки объекта). Выборки по умолчанию пересоздаются при изменении структуры класса.
  28. Основная выборка по умолчанию класса (редактирования в табличной форме) наследуется от основной выборки класса-предка для данного класса.
  29. Выборки, более точно настраиваемые для редактирования объектов класса, как правило, наследуются от выборок по умолчанию, с целью обеспечения автоматической поддержки изменений, производимых в классе (например, добавления нового атрибута). При пересоздании выборок по умолчанию, наследуемые от них выборки присоединяются к вновь созданным.
  30. Выборки предназначены для работы с любыми серверными данными, будь то таблицы метамодели или пользовательские классы.

 


Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.)