Презентация на тему Особенности реализации учетных задач в условиях существенной динамики бизнес-процессов

учет
Оперативный учет
…

конкретное место внедрения (если таких мест много)
Сложность внесения

изменений в ранее внедренное приложение при изменении условий ведения бизнеса
Взаимное проникновение OLTP и OLAP. Низкая оперативность OLAP-обработки.
Сложность настройки репликации
Мониторинг и управление уже настроенной репликацией должны производить специалисты прикладной области, а не DBA
Неоднозначность понятия «объект». Изменение со временем характеристик, идентифицирующих объект (наименование, ИНН, номер паспорта, ФИО и т.п.)
Контроль за вводом, модификацией и удалением информации должен осуществляться руководителями соответствующих подразделений, а не DBA

Жесткость приложения

Недостатки инструментария (РСУБД)

Индексы
Представления
Триггеры
Отчеты
Для специалиста в прикладной области

Документы

Журналы
Реестры
Регистры (бух.счета)
Отчеты

необходимо хранить информацию
Родилась
В 16 лет сменила имя и получила

паспорт

В 22 года вышла замуж и взяла фамилию мужа

Иванова Фёкла Васильевна
Без паспорта

В 30 лет получила паспорт российского образца

Иванова Ольга Васильевна
V-ЛЛ 1111111

Петрова Ольга Васильевна
V-ЛЛ 1111111

Петрова Ольга Васильевна
11 22 333333

Учетное время

Родился

Об этом объекте тоже нужно хранить информацию

Сидоров Сидор Сидорович
Без паспорта

Это один и тот же объект

А это уже другой объект

НЕОБХОДИМО ИСПОЛЬЗОВАТЬ СУРРОГАТНЫЕ КЛЮЧИ !

объекта
ООО «Азот»
ID учетного времени
ЗАО «Азот»
ООО «Гелий»
ID календарного времени
ЗАО «Азот»
ООО

«Азот»

ЗАО «Азот»

t учетное

t календарное

ООО :

ЗАО :

ООО «Азот»

ООО «Гелий»

Организация - покупатель

ООО «Азот»

ЗАО «Азот»

системных и главных полей
(история на календарном времени)
Таблица пользовательских полей
(актуальные

записи)

Таблица пользовательских полей
(история на календарном времени)

1

∞

Справочник создается после ввода в таблицы метаданных его описания и установки флага готовности метаданных.
Справочник представляется тремя VIEW с instead-триггерами, скрипт создания которых генерится автоматически.
Для хранения значений пользовательских полей используется тип sql_variant. Null значения НЕ хранятся.
В отличие от ALTER TABLE можно удалить столбец, а затем вернуть обратно вместе с данными.

поэтому отсутствуют конфликты репликации, которые могут возникать на полях

с identity.
В репликации из 4-х таблиц участвуют только две – таблицы актуальных записей. Остальные формируются автоматически триггерами.
Поскольку в две таблицы, участвующие в репликации, записи только добавляются (insert) конфликты репликации на уровне взаимодействия SQL-серверов отсутствуют.
Для всех серверов используется единая схема приема актуальности записей на основе глобального календарного времени (например GMT). Актуальной считается последняя по глобальному времени запись.
Управление репликацией можно производить на уровне логики высокого уровня с помощью программно управляемых фильтров, накладываемых на две реплицируемые таблицы.
В случае выполнения на разных серверах конфликтных действий по отношению к одним и тем же данным сервера автоматически приводятся в единое состояние, и на обоих серверах в истории модификации записи сохраняется информация о конфликте. Конфликт может быть разрешен специалистом прикладной области восстановлением нужной версии записи.

актуал. польз. полей
Табл. истории систем. полей
Табл. истории польз. полей
Trigger

insert

Сервер №2

VIEW справочника

insert

update

delete

Instad-триггеры

Табл. актуал. систем. полей

Табл. актуал. польз. полей

Табл. истории систем. полей

Табл. истории польз. полей

Trigger insert

Trigger insert

Trigger insert

Конфликт!

Конфликт!

удаленные записи (поиск пропавшей записи)

Дата и время [datetime]
Деньги [money]
Логическое [bit]
Число

с плавающей точкой [real]

Число с плавающей точкой двойной точности [float(53)]

Число с фиксированной точкой [numeric(19,4)]

Тип SQL

Измеряемая величина [float]

Одно значение из набора [uniqueidentifier]

Множество значений из набора [uniqueidentifier]

Ссылка на справочник [uniqueidentifier]

Множество значений из справочника [uniqueidentifier]

справочников, можно ступенчато открывать не только два справочника, а

произвольное их количество

поля за группами и элементами
Справочник 1
Справочник 2

Подчинение справочников друг

другу

Справочник 3

Справочник 1

2
Уровень 3
Уровень 4



Есть перечень свойств, но нет их значений
Наследование

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

Свойство1=77

Свойство2=«RU»

Свойство1=88

Свойство2=«US»

Назначение значений свойствам

Наследование перечня свойств вместе со значениями приводит к эффекту наличия различных default-значений для разных ветвей справочника

Свойство3=“18/04/2002”

В этой части дерева собственный набор свойств. С помощью полей такое сделать невозможно.

Свойство3=“18/04/2002”

по запросам на сервер
Табличная часть.

Вывод содержимого только
полей и только

тех записей,
которые находятся внутри
выделенной в дереве
группы.

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

смысл для всех записей справочника (таких как, «наименование»). А также атрибутов, по которым требуется часто выполнять упорядочивание записей. Все остальные атрибуты лучше представлять в виде свойств.

и групп
Права на модификацию перечня свойств
Правила подчинения

записей в дереве

В подчинении у одной группы элементы разного типа!
НЕЛЬЗЯ!

На одном уровне элементы разного типа.
МОЖНО!

образующим для проекции.
Проекция реализуется на VIEW и «системной»

UDF выборки поддерева.
Скрипты VIEW и Instead-триггеров делаются вручную, а не формируются автоматически. В Instead-триггерах реализуется логика, по которой добавляемые в проекцию записи сами распределяются в нужные ветви дерева.
Проекции, основанные на выборке поддерева, работают медленно. Модификация или добавление одной записи может привести к невидимому добавлению в дерево «виноградных гроздей» групп.

Проекция на справочник

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

справочников.
Систематизируется и упрощается поддержка журнализации (отслеживание модификации информации

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

соответствии со старой бизнес-логикой
Возможная утеря части старых данных

из-за их несовместимости с новой бизнес-логикой

Можно вносить изменения в бизнес-логику и в структуру данных

во время работы пользователей
Новая версия приложения 100% совместима со старой

документа может быть описана содержимым иерархического справочника
На структуру

документа распространяется версионность, приемы репликации и т.д.

документов одних на базе других настраивается заранее заданием соответствия

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

моментальный и протяженный. Моментальный не имеет версий на оси

учетного времени. Это основной вид документа для учетных задач (накладные, счета и т.п.). Он двигает регистры.
Протяженный документ напрямую не двигает регистры. Он является группирующим для множества моментальных. Пример протяженного документа – договор.
По оси учетного времени поддерживается версионность структуры и бизнес-логики регистрации экземпляра.
Сессия ввода/редактирования документа может длиться несколько дней с промежуточными сохранениями.
Черновик – редактируемая заготовка экземпляра документа. Процесс его модификации не протоколируется. Изменение его содержимого не влияет на журналы документов и регистры.
Беловик получается из черновика установкой статуса. В этот момент протоколируется все содержимое документа разом. Запускается бизнес-логика отражения его содержимого в регистрах. Документ отображается в журналах документов.
Для изменения документа сначала ему присваивается статус черновика – при этом из системы удаляется вся информация, которая в ней ранее появилась в результате регистрации документа.
По оси календарного времени регистрируются только моменты изменения статуса черновик/беловик с протоколированием содержимого документа на этот момент. Реплицируются моменты изменения статуса.

и настраиваемый.
Глобальный журнал – один. В нем регистрируются

все документы. Отражаются обязательные для всех документов поля – учетная дата, номер (а также автор, дата модификации, и тип документа).
Локальный журнал создается автоматически по одному на один вид документа. Он содержит значения всех полей бланковой части документов данного вида.
Настраиваемый журнал создается пользователем для удобства поиска документов разного вида. Задается перечень документов, которые должны в нем регистрироваться и задается перечень полей журнала. А также сопоставление полей документов различных видов полям журнала.
Информация журналов не реплицируется. Журналы формируются триггерами по появлению в системе информации о новых документах.

за период, расход за период)
Остатки на определенный момент

предоплату

Постановка товара в мягкий резерв до момента прихода денег.

Оплата

в срок не поступила – снятие товара с резерва. Перевод в свободный остаток.

Товар в свободном остатке

Товар в мягком резерве

Товар в долгосрочном резерве

Задолженность перед покупателем

товара в мягкий резерв до момента прихода денег.

Оплата в

срок не поступила – снятие товара с резерва. Перевод в свободный остаток.

НЕОБХОДИМО ПЕРЕПРОВЕДЕНИЕ ДОКУМЕНТОВ, ОТНОСЯХИХСЯ К БОЛЕЕ ПОЗДНИМ ПЕРИОДАМ!!!

Чтобы не делать перепроведение ВСЕХ документов более поздних периодов, необходимо хранить граф зависимостей документы-показатели-документы

выходят за пределы одного уровня зависимостей
∞
∞
1
1
N1
N2
N1* N2
Много!
Группы N1
∞
∞
1
1
Группы N2

N1

<< N2

<< N1*N2

2. Уменьшение числа ссылок за счет промежуточной группировки

– только с целью защиты информации от случайной модификации.

Допускается «закрытие» только части информации, а не всей за нужный период.
Регистры НЕ реплицируются.
Содержимое регистров формируется автоматически на базе реплицируемых документов.
Регистры содержат картину данных по всей оси учетного времени. Можно получать любые срезы и даже планы будущего.
Бизнес-логика реализуется UML-схемами.
Сами схемы являются частью реплицируемых данных.
Репликация бизнес-логики легко реализуется в рамках общей концепции.
Никакие операции не требуют прерывания работы пользователей (изменение структуры данных, изменение бизнес-логики, «закрытие» периодов)

Существенно упростить сопровождение ранее внедренного приложения.
Решить проблемы с

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

Предлагаемая концепция позволяет:

получать ответы на ~95% вопросов. По справочникам, журналам документов,

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