Статусная модель в бизнес анализе что это

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

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

Задача

Рассмотрим довольно широко распространенную ситуацию на рынке: вы разработали для заказчика (например, сети магазинов розничной торговли) мобильное приложение с возможностью оформления заказа на самовывоз. Но в скором времени планируется добавить возможность оформления заказа с доставкой на дом. У клиента нет собственной службы доставки, для оказания данной услуги будут привлекаться партнеры.

Для снижения тарифов на доставку и риска попадания в зависимость от конкретного партнера, клиент принял решение заключить договор сразу с несколькими курьерскими службами. Как итог: команде разработки необходимо реализовать несколько интеграций с системами курьерских служб.

После изучения процессов обработки заказов курьерскими службами заметим, что бизнес-процесс обработки заказа у каждого партнера имеет существенные отличия.

Как видно на рисунке выше:

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

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

А есть другие варианты?

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

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

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

Поскольку часть sms-сообщений не будет иметь к заказу никакого отношения, если оператор будет фиксировать на листе учета заказов все полученные сообщения, он очень быстро запутается. Если позвонит клиент и спросит: “Где сейчас находится мой заказ?”, оператору придется пролистать переписку, чтобы найти сообщение, касающееся именно заказа. Поэтому необходимо фильтровать сообщения, которые курьеры присылают оператору.

А на листке учета заказов фиксировать только важную информацию.

Кажется, я все понял!

Курьеры-иностранцы – это партнеры по доставке, а sms-сообщения, которые они присылают оператору – это статусы заявки на доставку, которые наше приложение получает от систем курьерских служб. Оператор, принимающий заказы – это и есть наше приложение.

Для того, чтобы решить задачу нам остается только:

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

И что, никаких подводных камней?

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

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

Заключение

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

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

Если у вас тоже есть подобный опыт, поделитесь, пожалуйста, в комментариях.

В корпоративных системах есть понятие статуса. В CRM это “холодный”, “горячий”, “новый”, “закрыт”. В документообороте — “Зарегистрирован”, “На согласовании” и “Исполнен”. Через статусы можно эмулировать бизнес-процессы, но до определенной степени. О том, как (и зачем) переходить от “статусов-стадий” к процессам читайте в этой статье. Она сложная, приготовьтесь.

6 проблем статусов

Статусы — это способ контролировать состояния заявок, договоров, сделок. Они отлично работают пока статусов немного, статусы не влияют друг на друга. Статусы работают, пока могут перепрыгивать туда-сюда по воле пользователя или строго в одном направлении. Но при усложнении логики у статусов появляются проблемы. Статусы можно воспринимать как FSM, конечный автомат (см. вики).

1. Нужно помнить прошлое

В начале работы по статусам можно переключаться туда-сюда. С точки зрения программистов такая логика реализуется атрибутом в таблице сущности.

Однажды окажется, что в предыдущее состояние переходить нельзя.

У разработчика будет 2 пути:

• Выразить факт прохождения статуса “Новый” через атрибут сущности. Например:  есть “Документ” ,  добавляем атрибут “Был в статусе “Новый”. При попытке перевести “Документ” в статус “Новый” проверяем атрибут.
• Добавить дополнительную таблицу пройденных статусов и проверять в ней.

Если развивать эту мысль, то при любой смене статуса нужно перепроверить все атрибуты.

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

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

2. Нужно N-состояний одновременно

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

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

3. Рекурсия

Существует риск впасть в рекурсию, если используется автоматическое переключение статусов. Чтобы защититься от рекурсии нужны дополнительные правила. Это бессмысленный код, который не создает ценности.

4. Комплексный рост сложности и скорости разработки

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

• 2 атрибута и 2 статуса дают 4 перестановки.
• 3 атрибута и 3 статуса дают 27 перестановок.
• 5 атрибутов и 5 статусов дают 3125 перестановок.

5. Доказательство проходимости и сложность тестирования

Тестировать статусы сложно — на каждую перестановку нужно писать тест. А если поменялись статусы или атрибуты, то нужно всё перепроверять иили переписывать.

6. Несколько сущностей меняют статусы друг другу

Представьте:

• Из одного документа нужно родить 4 новых,
• Прогнать их независимо
• Переопределить статус основного, в зависимости от результатов обработки указанных 4 документов

Это много кода и тестов, которые не имеют ценности.

Проблемы находятся на уровне разработки и не решаются на этом уровне. Я не могу придумать действия, которые в долгосрочной перспективе избавили систему статусов от перечисленных недостатков. Значит надо выходить за её границы.

Переходим к процессам

Нужно вводить отдельную сущность — экземпляр процесса и процесс.

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

В этом смысле это классическое сравнение FSM и сетей Петри. На эту тему написано несколько научных статей, например эта. 

Для сложной структуры нужна правильная модель предметной области. BPM-движки или BPMS-системы (например Camunda) все предлагают такую структуру:

• Deal — бизнесовая сущность. Она может участвовать в большом количестве Process Instances. Во всех процессах бизнес-сущности свои.
• Process Instance — конкретный запуск процесса по сущности.
• Process Definition — описание процесса, которое содержит все возможные варианты его развития.
• Activity Definition — описание конкретной задачи(статуса), которое может быть достигнуто в процессе.
• Activity — конкретная задача, которая выполняется сейчас, с возможными переходами.

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

Алгоритм перехода

Для описания процессов будем использовать BPMN — это простая и понятная нотация, которая к тому же исполнима. Это значит, что существует софт, который возьмёт за вас заботу о Process Definition, Activity Definition, Process Instance и всем вокруг. Останется позаботиться об конкретных Activity и описании процессов.

1. Стадии как промежуточные события

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

Нарисуем её в формате BPMN:

Для каждого статуса используем промежуточное событие. Из промежуточного события не может выходить больше 1 потока управления, поэтому в таких местах ставим развилки.

В BPMN процессы должны иметь стартовое и завершающее событие. Стартовое — это значит что в рамках инстанса оно выполняется только раз, а до его выполнения инстанса нет. Завершающее — это значит процесс (или токен) завершаются на этом событии и дальше нет никаких работ( или статусов), которые необходимо выполнять.

Судя по схеме, кандидатами на стартовое событие это A, а завершающее — это F.

В BPMN стартовое событие не может иметь входящих потоков управления. Статус A выполнял 2 функции — старт процесса и показывал выполнение какой-то работы. Нарисуем это:

2. Разбираемся с развилками

Статусы — это отражение того, что-то то было выполнено или должно быть выполнено, но в неявном виде. А при создании процесса мы должны вытащить это явно на диаграмму.
Почему после статуса E можем перейти в статус C или статус F? Кто-то или что-то принимает решение, что нужно перейти куда-то. Если это решение принимает человек, то изобразим это так:

Если решение принимает скрипт, то можно изобразить так:

Сделаем тоже самое со статусами C->D  или C-A1:

3. Выясняем, почему меняются статусы

Между А1 и B  что-то происходит, из-за чего сущность меняет свой статус. Нарисуем:

4. Уточняем бизнес-смысл происходящего

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

Мы перестаём перещелкивать статусы, а начинаем делать работу в рамках процесса.

5. Проверяем квадратики: достаточность информации

Берём 2 квадратика и задаём вопрос — действительно ли после выполнения первого квадратика возможно выполнить второй:

Добавляет задачи, которые пропустили:

6. Проверяем квадратики: а что если?

У каждого квадратика подразумеваем успешное выполнение. А что если задача будет выполнена не успешно — например при проверке контрагента он оказался плохой? Нарисуйте такие развилки и реакции на них:

Поздравляю, теперь у вас есть первая версия процесса.

Что мы получаем и чем платим

Процесс избавляет вас от проблем:

• Прошлое не нужно помнить — за счёт наличия маркера текущих Activity вы знаете состояние процесса. Не нужно сохранять это состояние на сущность. Это разделяет сущность от её процессов, что дает возможность развиваться независимо.
• N-состояний — за счёт process definition и activity definition, а так же независимости сущности от процесса, возможно иметь сколько угодно одновременно состояний в процессе.
• Рекурсия — не страшна, т.к. мы знаем все возможные переходы и нам не больно их учитывать. Всегда знаем путь, по которому сущность дошла до текущего состояния.
• Рост сложности — избавлены от него, т.к. данные разделены и от процесса, есть понятие Activity, являющееся кирпичиком процесса. Activity может добавлятьсяредактироваться независимо от остальных элементов процесса.
• Доказательство проходимости — подпроцессы на BPMN это подмножество сетей Петри. Существует возможность математически доказать,что сеть Петри проходима.
• Несколько сущностей — process definition могут включать в себя другие process definition, в которых обрабатываются другие сущности.

За это мы платим:

• Дорого в реализации — нужно врубиться в технологии BPMS, понять как работает BPMN. У меня на онлайн-курсе 1204 можно сократить стоимость и срок осмысления.
• Нужно врубаться в процессы — подход с процессами требует от айтишников понимания процессов и бизнеса.

Где хороши статусы

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

В итоге

Статусы хороши в начале разработки решения, но плохи при сложной логике процесса. Готовьтесь к внедрению BPM-движка,  если добавление нового статуса требует больше недели.

Как вам статья? Приходилось ли работать со статусами и страдать? Напишите в комментарии и поделитесь статей в соц.сетях.

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)

Структурируй это: как в ДОМ.РФ выстроена работа над крупными проектами

Плюсы, минусы, подводные камни спецификаций — на примере Единой информационной системы жилищного строительства (ЕИСЖС).

Информационно и технически Единая информационная система жилищного строительства (ЕИСЖС) позволяет переводить отрасли жилищного строительства на проектное финансирование.

Каждый сервис внутри ЕИСЖС — это сложная информационная система с большим количеством интеграций, и поэтому увеличение количества разрабатываемых сервисов требует структурированного подхода к аналитике всех проектов.

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

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

Основа нашего подхода в части аналитики — шаблон спецификации требований, который разработан с учетом особенностей систем внутри ЕИСЖС и рабочих процессов при разработке программного обеспечения внутри ДОМ.РФ.

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

В отличие от технического задания (как приложения к договору) или постановки — в виде описания в трекере задач, — спецификация описывает актуальные требования к системе с учетом всех ранее выполненных изменений. Система меняется, и вместе с ней меняется спецификация. По спецификации можно отследить как путь развития системы, так и актуальное состояние системы.

Пользователями спецификации являются почти все участники процесса:

• Бизнес-заказчик;

• Аналитик;

• Архитектор;

• Разработчик;

• Тестировщик;

• Технический писатель.

 Вот, что дает нам единый подход, понятный и привычный всем участникам процесса развития ЕИСЖС:

• позволяет сократить время на погружение нового специалиста в проект, а также на переключение сотрудников ИТ-подразделения между проектами;

• снижает количество вопросов между участниками проектной команды, а значит — и затраты времени на каждый этап разработки. Разработчик всегда знает, где описаны требования, тестировщик не тратит время на поиск описания сценариев, а технический писатель может разработать полный комплект отчетной документации только на основе уже готовых постановок;

• облегчает восприятие IT-информации для сотрудников бизнес-подразделений, в интересах обеспечения деятельности которых разрабатываются сервисы;

• приводит к тому, что спецификация согласуется с заказчиком, поэтому записи спецификации являются зафиксированной договоренностью между исполнителем и заказчиком;

• позволяет определить, каковы были требования в любой момент времени за счет того, что спецификация поддерживает историчность изменения требования — на случай противоречий между любыми участниками процесса. Следовательно, если система работает, как описано в спецификации, то это не может считаться багом, и все новые требования должны стать доработкой.

В основе рассматриваемого шаблона лежит подход Boundary-Control-Entity, который лучше других подходит к разрабатываемым нами системам и проектам.

Его принцип — в декомпозиции требований на три слабосвязанных слоя: требования к данным, требования к функциям и требования к интерфейсу.

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

Слои описываются отдельно, но между ними присутствуют связи. Такой подход позволяет минимизировать влияние изменений в одном слое на другой. Так, например, изменения в интерфейсе не должны оказывать существенного влияния на функции или данные.

Как оценить качество нашей спецификации?

Мы используем основные классические свойства:

• Полнота. Совокупность элементов спецификации должна исчерпывающе описывать поведение системы. Не должно быть скрытых функций, не описанных в спецификации – это баги! Все, что есть в спецификации, должно быть и в нашей системе — мы можем провести аналогию спецификации с программным кодом: спецификация – тот же код, только написанный другим языком.

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

• Атомарность. Спецификация не может быть разбита на более мелкие требования без потери завершенности.  Каждый элемент не может быть декомпозирован на более мелкие требования. При этом необходимо придерживаться здравого смысла, не вынося в отдельное описание каждое поле. В нашем случае мы пришли к тому, что отдельная страница спецификации (страница wiki) должна содержать описание одного элемента, такого как “сущность”, “функция”, “элемент интерфейса” (например, витрина данных, pop-up, меню и т.д.).

• Непротиворечивость. Требование не противоречит другим требованиям. Понятие непротиворечивости тесно связано с понятием завершённости. Одно требование – одно описание!

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

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

Как упоминалось выше, в нашем описании мы используем большое количество слоев. На рисунке ниже приведен раздел описания одной из систем в составе ЕИСЖС, которая называется «Каталог жилищных программ»:

Раздел организационных материалов содержит ссылки на бэклог (сам бэклог ведется в Jira, однако ссылка на него обязательно присутствует в wiki), стенды, страницу проекта в git, ссылки на рабочие чаты, список участников команды, протоколы совещаний. Данный раздел ведется руководителем проекта и используется всеми участниками команды для нахождения в едином информационном поле о текущем состоянии проекта.

Раздел архитектуры содержит схему развертывания. В нем отдельно следует выделить страницу нефункциональных требований. Страница фактически ведется по ГОСТ 34. Нефункциональные требования важны как при проектировании архитектуры системы, так и при разработке отчетной документации техническими писателями.

  Основной рабочий раздел аналитика – раздел спецификация требований. В нашем случае мы поддерживаем на всех проектах следующую структуру описания требований:

• Концепция продукта (или паспорт проекта). Краткое определение системы: для чего нужна, кто является пользователями, какие основные бизнес функции автоматизирует, высокоуровневая идея продукта, его полное и сокращенное название. Краткое описание назначения продукта/системы. Для систем, которые были созданы давно или другими командами, данный раздел может остаться пустым, т.к. восстановление утраченной информации и первоначальной цели проекта может быть затруднительно. Однако для новых проектов его заполнение обязательно, т.к. помогает и исполнителям, и заказчикам точнее сформулировать назначение системы в целом.

• Глоссарий. Содержит ссылку на единый глоссарий всех систем ЕИСЖС, но также расширяет его уникальными для данной системы терминами и определениями.

• Бизнес-модель. Описание предметной области (сущности, автоматизируемые бизнес-процессы). Аналитик описывает понятными айтишнику словами основные требования к общей концепции системы и к бизнес-процессам в целом, основываясь на нормативной документации или иных документах, регламентирующих функции системы. До начала разработки содержание раздела согласуется с заказчиком (в нашем случае — сотрудниками бизнес-подразделений ДОМ.РФ) и помогает выстроить единый взгляд на бизнес-процессы продукта.

• Описание пользователей. Кто является пользователями (в т.ч. и внешние системы). В сценариях данные пользователи должны будут выступать в качестве участников. Позволяет выявить лишних пользователей или недостаточность пользовательских ролей. При описании пользователей необходимо следить, чтобы в сценариях не было пользователей, не описанных в этом разделе, а также чтобы все описанные здесь пользователи выступали участниками в планируемых сценариях.

• Требования к сущностям. Должна быть приведена модель данных со связями между сущностями. Для каждой сущности логической модели должно быть указано назначение сущности. Каждый элемент должен описывать одну сущность.  Обязательно указывать, как используется сущность, при этом можно дать ссылки на сценарии и пользователей. Далее необходимо расписать атрибуты сущности. Описание атрибутов приводится в виде таблицы, содержащей наименование атрибута, тип атрибута (текстовый, числовой, дата и т.д.), кратность и обязательность заполнения атрибута, способ заполнения (автогенерация в системе, вычисляемое поле или заполняется пользователем). Если поле заполняется одним из возможных значений справочника, то необходимо дать ссылку на описание данного справочника.

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

Отдельный вид сущности – статусная модель. Помимо статусной модели в виде таблицы необходимо приводить варианты переходов между статусами, как минимум в виде последовательности статусов в той же таблице, либо в виде отдельной диаграммы.

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

• Требования к функциям. Рекомендуется приводить в виде вариантов использования (use case), где это возможно. Надо обязательно указывать участников, цель, активаторы (какое событие является начальным), предусловия и постусловия выполнения сценария. Если в сценарии возможны различные ветки, необходимо описывать все альтернативные сценарии. Важно помнить: если не описано, значит, не реализовано. Значит, будет выявлено как баг после выпуска системы в прод. Нужно определить логическую модель основных функций (диаграмма прецедентов).

• Требования к интерфейсу. Можно разделить на два вида: пользовательский интерфейс и программный (API).

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

Для разработки макетов наши дизайнеры используют figma. Однако при описании пользовательских интерфейсов лучше не ограничиваться ссылкой на figma. Мы рекомендуем помимо ссылки приводить так же скриншоты: figma сторонний инструмент, и мы не может гарантировать его доступность в будущем. Вкладывание скриншотов позволяет отследить изменения в макетах figma, которые не были описаны по тем или иным причинам. Однако следует помнить, что в случае отсутствия дизайнера на проекте возможны случаи “отставания” макетов и скриншотов от описания, поэтому считаем, что для разработчика приоритетно описание.

Для каждого элемента интерфейса необходимо указать:

• обозначение;

• тип (например, выпадающий список, текстовое поле, кнопка);

• требования ФЛК (при наличии);

• источник данных, т.е. маппинг экранной формы и сущностей, либо формулу для вычисления, если поле вычисляемое, либо условные выражения, которые будут использованы для заполнения поля);

• условия доступности/видимости;

• комментарий при необходимости.

Описание программных интерфейсов также стандартизировано. В wiki должны быть созданы разделы для интерфейсов разрабатываемой системы и для используемых интерфейсов смежных систем (при наличии).

• Требования к шаблонам и печатным формам

Данный раздел необходим, если в системе есть генерируемые печатные формы либо входящие документы, которые должны быть оформлены по шаблону. Все требования к этим документам приводятся в отдельном разделе, который должен содержать маппинг полей шаблона/документа полям БД для печатных форм, заполняемых значениями из БД, формулы для расчета показателей в случае необходимости. Для документов, которые загружаются в систему извне, приводятся требования к ФЛК, которые необходимо выполнить при приеме документа в систему. В разделе должны быть приложены исходники/шаблоны документов, которые должны актуализироваться их по мере необходимости.

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

1. Не дублируйте описания, используйте гиперссылки между элементами спецификации.

2. Ведите лист изменений (см. рисунок) на каждой странице wiki с указанием причины внесения изменений (ссылка на договор, задачу jira или иной первоисточник). При такой записи вам будет намного проще восстановить ключевые моменты изменения системы вместо того, чтобы разбираться в истории сохранения страниц без понимания, почему были внесены те или иные изменения.

3. Выделяйте изменения при доработках элементов спецификации любым удобным вашей команде способом. Например, на рисунке ниже видны два этапа внесения изменений в требования ФЛК, каждое из которых было вызвано внесением изменений в нормативные документы, регламентирующие функционирование системы.

В комментариях к этой же странице обязательно указывайте причину внесения изменений, например:

Стабилизация экономики ведет к росту конкуренции и повышению важности принятия правильных решений для успешной работы предприятий.

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

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

Константин Борисович Лисянский, архитектор хранилищ данных, компания «Диасофт». Ему можно написать по электронной почте klissianski@diasoft.ru

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

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

Анализ доходов актуален для любого предприятия и позволяет формировать «уникальные» продукты для каждого «уникального» клиента исходя из максимизации прибыли в долгосрочной перспективе, правильно выстраивать ценовую политику предприятия, делать клиентам специальные предложения, выделять сегменты, продукты и услуги, которые стратегически важны для предприятия.

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

Комплекс задач по созданию хранилища данных

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

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

При составлении проектного плана необходимо учитывать специфику каждого этапа, следить за рамками проекта, подбирать специалистов соответствующей квалификации. Наполнение хранилища данных — один из ответственных этапов, занимающий, по различным оценкам, до 70% ресурсов проекта. На это также следует обратить внимание при планировании.

Далее в статье мы уделим внимание выбору архитектуры хранилища данных, а также моделированию хранилищ и витрин данных.

Основные отличия систем поддержки принятия решений от традиционных оперативных систем

Ввиду того что приемы проектирования систем поддержки принятия решений на основе хранилищ данных и приемы проектирования традиционных систем различны, следует упомянуть о причинах этого, кроющихся в отличиях между двумя видами информационных систем. Основные отличия между традиционными оперативными информационными системами и системами поддержки принятия решений (СППР) обусловлены задачами, для решения которых создаются системы: обеспечение ежедневной работы предприятия одной системой и поддержка принятия решений — другой. На данный момент существует масса публикаций, в которых эти отличия рассматриваются весьма подробно [4, 6, 8, 15].

Мы же в данной статье сконцентрируемся на аспекте проектирования совокупности баз данных на предприятии — операционных («традиционных»), исторических (хранилищ) и приспособленных к решению специфических задач («витрин»; см. табл. 2).

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

Архитектура СППР

Известно несколько способов построения СППР, и большинство из них основано на технологиях хранилищ и витрин данных.

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

1. Функциональная СППР.
2. Независимые витрины данных.
3. Двухуровневое хранилище данных.
4. Трехуровневое хранилище данных.

Функциональная СППР

Функциональная СППР (рис. 1) является наиболее простой с архитектурной точки зрения. Такие системы часто встречаются на практике, особенно в организациях с невысоким уровнем аналитической культуры и недостаточно развитой информационной инфраструктурой.

Рис. 1. Функциональная СППР

Функциональная СППР характерна тем, что при анализе данных система использует данные из оперативных систем.

Преимущества:

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

Недостатки:

• единственный источник данных, потенциально сужающий круг вопросов, на которые может ответить система;
• оперативные системы характеризуются очень низким качеством данных с точки зрения их роли в поддержке принятия стратегических решений; в силу отсутствия этапа очистки данных данные функциональной СППР, как правило, также обладают невысоким качеством;
• большая нагрузка на оперативную систему — сложные запросы могут привести к остановке работы оперативной системы, что весьма нежелательно.

СППР с использованием независимых витрин данных

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

Рис. 2. Независимые витрины данных

Преимущества:

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

Недостатки:

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

СППР на основе двухуровневого хранилища данных

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

Рис. 3. Двухуровневое хранилище данных

Преимущества:

• данные хранятся в единственном экземпляре;
• минимальные затраты на хранение данных;
• отсутствуют проблемы, связанные с синхронизацией нескольких копий данных;
• данные консолидируются на уровне предприятия, что позволяет иметь единую картину бизнеса.

Недостатки:

• данные не структурируются для поддержки потребностей отдельных пользователей или групп пользователей;
• возможны проблемы с производительностью системы;
• возможны трудности с разграничением прав пользователей на доступ к данным.

СППР на основе трехуровневого хранилища данных

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

Рис. 4. Трехуровневое хранилище данных

Преимущества:

• создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных нормализованных данных;
• имеется (построена) общая структура данных предприятия;
• витрины данных синхронизированы и совместимы с общей структурой данных предприятия;
• существует возможность сравнительно легкого расширения хранилища и добавления новых витрин данных;
• гарантированная производительность.

Недостатки:

• избыточность данных, ведущая к росту объема хранилища;
• требуется согласованность с принятой архитектурой многих областей с потенциально различными требованиями (например, скорость внедрения иногда конкурирует с требованиями следовать архитектурному подходу).

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

Подробное описание преимуществ и недостатков каждого варианта архитектуры можно найти в [2, 3].

Моделирование хранилищ данных

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

Особенности моделирования времени в хранилищах данных

Традиционные подходы к моделированию оперативных систем основываются, как правило, на статическом представлении реального мира. При этом если время и учитывается, то только в виде временных отметок создания записей и их модификации. С точки зрения моделирования времени хранилища данных принципиально отличаются от оперативных систем, и модели хранилищ данных более интенсивно используют временные отметки. Подробно об этом пишут Саймон [14] и Девлин [2].

Рис. 5. Модель снимков данных

Рис. 6. Событийная модель

Существует три способа моделирования изменяющихся во времени статусов:

• непрерывная модель — для хранения промежутков времени используется одно поле даты, при этом дата начала следующего периода совпадает с датой окончания предыдущего;
• начало и окончание — для хранения промежутков времени используется два поля — дата начала и дата окончания периода действия статуса;
• начало и длительность — для хранения промежутков времени используется одно поле даты (дата начала) и поле длительности периода.

Наибольшее распространение при создании статусных моделей получил способ «начало и окончание» (рис. 7).

Рис. 7. Статусная модель

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

Выбор ключей

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

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

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

Использование ключей из оперативных систем

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

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

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

Генерация ключей

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

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

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

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

Вопросы целостности данных

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

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

Моделирование витрин данных

Приемы моделирования витрин данных отличаются от приемов моделирования хранилищ данных в силу различных требований к структурам данных. Если основной задачей хранилища данных является хранение консолидированной исторической информации, то витрина данных строится с учетом требований по доступу к данным и представления информации.

Как правило, для моделирования витрин данных используются схемы типа «звезда» и «снежинка». Популяризатор данного подхода моделирования Ральф Кимбал разработал основные концепции схемы «звезда» [7, 8, 9]. Некоторые исследователи даже попытались подвести под практические подходы Кимбала теоретическую базу [10]. Давайте познакомимся с этими подходами немного поближе.

Схема «звезда»

Схема «звезда» — популярный тип модели базы данных для витрин данных. Данная структура характеризуется наличием таблицы фактов, окруженной связанными с ней таблицами измерений. Запросы к ней включают простые соединения таблицы фактов с каждой из таблиц измерений. Схема «звезда» характеризуется небольшой избыточностью данных и высокой по сравнению с нормализованными структурами производительностью. Некоторые промышленные СУБД и инструменты класса OLAP/Reporting умеют использовать преимущества схемы «звезда» для сокращения времени выполнения запросов.

На рис. 8 изображен пример использования схемы «звезда» для анализа остатков на счетах банка и количества транзакций в разрезе времени, клиентов, счетов, продуктов, отделений, статусов счетов. Модель выполнена с использованием нотации IDEF1X. Данная модель позволяет ответить на широкий спектр аналитических вопросов. Например: «Посчитать средний остаток и количество операций на депозитных счетах, открытых более года назад клиентами отделения «Тверское», проживающими в городе Зеленоград». Специалисты, знакомые с автоматизированными банковскими системами, могут убедиться в том, что на подобный запрос очень нелегко ответить с их помощью.

Рис. 8. Схема «звезда» для анализа остатков на счетах банка

Рассмотрим компоненты схемы «звезда».

Измерения

В технологии многомерного моделирования измерение (dimension) — это аспект, в разрезе которого можно получать, фильтровать, группировать и отображать информацию о фактах.

Типичные измерения, встречающиеся практически в любой модели:

• клиент;
• продукт;
• время;
• география;
• сотрудник.

Измерения, как правило, имеют многоуровневую иерархическую структуру. Например, измерение ВРЕМЯ может иметь следующую структуру: ГОД—КВАРТАЛ — МЕСЯЦ — ДЕНЬ.

Факты

Факты — это величины, обычно числовые, хранящиеся в таблице фактов и являющиеся предметом анализа. Примеры фактов: объем операций, количество проданных единиц товара и т. д.

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

Аддитивные факты

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

Полуаддитивные факты

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

Данную величину нельзя суммировать вдоль измерения ВРЕМЯ. Однако сумма остатков на счетах вдоль измерения КЛИЕНТЫ имеет вполне реальный смысл для анализа.

Неаддитивные факты

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

Специалисты рекомендуют моделировать неаддитивные факты таким образом, чтобы сделать их более аддитивными. Например, представить процент составляющими его величинами [1].

Более подробное описание фактов и их свойств можно найти в [1, 8, 9].

Таблицы покрытия

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

Схема «снежинка»

Данная схема (рис. 9) используется для нормализации схемы «звезда», при этом несколько сокращается избыточность в таблицах измерений.

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

Однако основным достоинством схемы «снежинка» является не экономия дискового пространства, а возможность иметь таблицы фактов с разным уровнем детализации, например фактические данные — на уровне дня, а плановые — на уровне месяца.

Моделирование времени в витринах данных

Витрины данных, как правило, характеризуются наличием явного измерения ВРЕМЯ. При этом структура данного измерения может меняться в зависимости от моделируемой предметной области и требований, предъявляемых пользователями к представлению времени.

Помимо стандартных атрибутов времени, как правило, возникает необходимость моделирования специальных атрибутов времени, таких как:

• недели;
• времена года;
• сезоны;
• выходные и праздники;
• рабочие смены.

Моделирование времени в витринах данных — достаточно сложный момент, освещение которого заслуживает отдельной статьи, мы же перейдем к обсуждению проблемы выбора инструментов для моделирования.

Выбор инструментов

Для создания и поддержки успешных моделей хранилищ и витрин данных необходимы соответствующие средства моделирования. В настоящее время на рынке представлено достаточно большое количество продуктов, предназначенных для проектирования традиционных баз данных, и специализированных средств, предназначенных для создания хранилищ и витрин данных. Приведем названия некоторых из них:

• CAST AppViewer (www.castsoftware.com)
• Computer Associates ERwin (www.ca.com)
• Embarcadero ER/Studio (www.embarcadero.com)
• Microsoft VisioModeler (www.microsoft.com)
• Oracle Designer (www.oracle.com)
• Popkin System Architect (www.popkin.com)
• Sybase PowerDesigner WarehouseArchitect (www.sybase.com)
• Visible Systems Visible Advantage Data Warehouse Edition (www.visible.com)

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

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

Поддержка методологий проектирования моделей

• Поддержка традиционного ER-моделирования (для моделирования хранилищ данных) и многомерного моделирования (для моделирования витрин данных).
• Поддержка различных методологий проектирования и нотаций (нотации Чена, Мартина, Баркера, IDEF1X, IE, ORM, UML, DFD и др.).
• Корректное преобразование моделей из одной нотации в другую.

Управление метаданными

• Открытый репозиторий метаданных (возможность обмена метаданными с приложениями класса ETL, OLAP/Reporting, data mining, репозиториями метаданных, инструментами контроля качества данных).
• Поддержка стандартов на хранение и обмен метаданными (ISO 11179, CWM, MDIS, CWMI, CDIF).
• Поддержка свойств, определяемых пользователем (UDP), — для расширения круга метаданных, поддерживаемых моделью.

Поддержка жизненного цикла моделей

Поддержка коллективной разработки моделей данных (контроль версий, check-in, check-out, разграничение доступа на уровне моделей и их отдельных объектов).
Гибкая система отчетности (отчеты обо всех объектах модели данных на всех уровнях, отчеты об изменениях и другие отчеты, возможность публикации отчетов в сети intranet).
Поддержка возможности проверки качества моделей (стандарты именования объектов моделей данных, проверка полноты описания объектов, автоматическая генерация запросов на проверку качества).
Многоплатформенность (поддержка генерации объектов для различных промышленных СУБД).
Поддержка повторного использования компонентов моделей (экономия ресурсов при разработке однотипных фрагментов).
Наличие встроенных средств разработки (макроязык, API) для тонкой настройки инструмента и автоматизации рутинных операций.
Поддержка обратного проектирования (reverse engineering) для обеспечения возможности восстановления моделей оперативных систем в случае их отсутствия.

Удобство использования

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

Заключение

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

Литература

1. Adamson C., Venerable M. Data Warehouse Design Solutions. John Wiley & Sons, Inc (1998). ISBN 0-471-25195-X.
2. Devlin B. Data warehouse: from architecture to implementation. Addison Wesley Longman, Inc. (1997). ISBN 0-201-96425-2.
3. IBM. «Business Intelligence Architecture on S/390. Presentation Guide». SG24-5747-00, IBM Corporation (2000).
4. IBM. «Business Intelligence Certification Guide». SG24-5747-00, IBM Corporation (2000).
5. IBM. «Data Modeling Techniques for Data Warehousing». SG24-2238-00, IBM Corporation (1998).
6. Inmon W. What is a data warehouse?//White Paper. http://www.billinmon.com//library/whiteprs/
   earlywp/ttdw.pdf
7. Kimball R. A Dimensional Modeling Manifesto//DBMS Magazine. August 1997.
8. Kimball R. The Data Warehouse Toolkit. Practical Techniques for Building Dimensional Data Warehouses. John Wiley & Sons, Inc (1996). ISBN 0-471-15337-0.
9. Kimball R. et al. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying Data Warehouses. John Wiley & Sons, Inc (1998). ISBN 0-471-25547-5.
10. McGuff F. Hitchhiker?s Guide to Decision Support (http://members.aol.com/fmcguff/dwmodel/).
11. Silverston, L. Inmon W., Graziano K. The Data Model Resource Book. A Library of Logical Data Models and Data Warehouse Designs. John Wiley & Sons, Inc (1997). ISBN 0-471-15367-2.
12. Winsberg, P. Modeling the Data Warehouse and Data Mart// InfoDB, 10, № 3, 1-10.
13. Львов В. Создание систем поддержки принятия решений на основе хранилищ данных//Системы управления базами данных. 1997. № 3.
14. Саймон А. Стратегические технологии баз данных. Глава 4. Склады данных//Системы управления базами данных. 1997. № 3.
15. Спирли Э. Корпоративные хранилища данных. Планирование, разработка и реализация. Т. 1. «Вильямс» (2001). ISBN 5-8459-0191-X.
16. Щавелев Л. В. Способы аналитической обработки данных для поддержки принятия решений//Системы управления базами данных. 1998. № 4-5.

Термины, использованные в статье:

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

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

Метаданные — любые данные, необходимые для поддержки процессов создания и использования хранилища данных. Метаданные включают информацию о физических данных, технических и бизнес-процессах, правилах и структуре данных организации.

Таблица измерения — таблица, хранящая информацию об измерении. Как правило, это таблица схемы «звезда» или «снежинка», имеющая первичный ключ, состоящий из одного атрибута.

Таблица покрытия — таблица, хранящая информацию об отсутствии фактов для определенных сочетаний измерений (например, отсутствие продаж определенных продуктов в определенные дни).

Таблица фактов — таблица в схеме «звезда» или «снежинка», использующаяся для хранения данных об анализируемых показателях.

Факт — величина, обычно числовая и аддитивная, хранящаяся в таблице фактов и являющаяся предметом анализа.

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