Сегодня 18 октября 2017 г. | 19:24 На главную Карта ресурсов INFMAN Написать письмо

«Универсальность модели бизнес-объектов при анализе информационных потребностей».


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

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

Одним из простых примеров, рассматриваемой в данной статье, является использование модели бизнес-объектов при анализе информационных потребностей. В разделе «Услуги»->«Система информационного менеджмента» рассказывалось об иерархической модели бизнес-объектов, которая позволяет представить предметную область в виде взаимодействующих объектов следующих видов:

BI (Business Information), BS (Business Sphere), BC (Business Catalog), BP (Business Process), BA (Business Action) (добавляются также другие лексические образования для расширения модели, например, BR (Business Registry)). Вследствие организации взаимодействия между объектами (экземплярами классов) подразумевается использование механизмов наследования, инкапсуляции и полиморфизма из практики объектно-ориентированного программирования.

Иногда некоторые объекты модели имеют незначительные отличия друг от друга и для удобства разработки оболочек хранения атрибутов бизнес-объектов в Базе Данных применяют слияние разных объектов в один бизнес-объект на основе сходства большинства атрибутов. Так происходит, к примеру, при взаимодействии 2 процессов: управление заказами и управление поставками. В первом случае заказ – это неполная поставка. Менеджер может составить заказ на покупку, но не знает, какой поставщик, по какой цене и когда поставит требуемый товар.

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

Имеем следующую структуру таблиц для хранения значений бизнес-объектов «поставка» и «заказ»:

Заказ

№ заказа Дата Получатель

Поставка

№ поставки Дата Получатель Поставщик Сумма

Поля №, дата, получатель имеют одинаковую структуру и характеристики данных (Тип, длина поля, значения по умолчанию и др.) Поэтому на физическом уровне проектирования Базы Данных получаем одну таблицу:

Закупка

Дата Получатель Поставщик Сумма

Преимущества данного подхода заключается в следующем:

  1. Все операции чтения/записи производятся с одной таблицей Базы Данных.
  2. Возрастает скорость OLAP-обработки, т.к. отсутствуют подготовительные операции переноса данных в хранилище данных.
  3. Данный подход позволяет строить банки данных (регламентированный доступ с возможностью фиксации бизнес-правил на стороне сервера приложений).
  4. Добавляя в полученные таблицы префиксы BA, BC, BP, получаем, что одна сущность (информационный объект) участвует в конкретных процессах, имея возможность перехода из одного процесса в другой без дополнительной бизнес-логики.
  5. Снижается стоимость разработки SQL-запросов при построении СУБД.

Ссылки на сайты наших клиентов:

 
Разработано web-development компания INFMAN © 2004-2005