что такое статусная модель
Как сварить кашу из микросервисов
Одной из причин популярности микросервисов является возможность автономной и независимой разработки. По сути микросервисная архитектура — это размен возможности автономной разработки на более сложный (по сравнению с монолитом) деплой, тестирование, дебаг и мониторинг. Но нужно учитывать, что микросервисы не прощают ошибок разделения ответственности. При неправильном разделение обязанностей возникают частые зависимые изменения в разных сервисах. И это намного больнее и сложнее, чем согласованные изменения в рамках разных модулей или пакетов внутри монолита. Согласованные изменения в микросервисах осложняется согласованной выкладкой, деплоем, тестированием и т.д.
И хотелось бы рассказать о различных паттернах и антипаттернах разделении ответственностей на микросервисы.
Сервис-сущность как антипаттерн
“Сервис-сущность” — один из возможных (анти)паттернов проектирования микросервисной архитектуры, который приводит к сильно-зависимому коду в разных сервисах и слабосвязанному внутри сервисов.
Большинству разработчиков кажется, что выделяя сервисы по сущностям предметной области: «сделка», «персона», «клиент», «заказ», «картинки», он следует принципам единственной ответственности, и более того, часто это кажется логичным. Но подход «сервис — сущность» может превратиться в антипаттерн. Происходит это потому, что большинство фичей или изменений затрагивают несколько сущностей, а не одну. В результате в каждом таком сервисе объединяется логика разных бизнес-процессов.
Для примера возьмем интернет-магазин. Мы решили выделить сервисы «продукт», «заказ», «клиент».
Какие изменения и в какие сервисы надо сделать, чтобы добавить доставку на дом?
Например, можно так:
Или какие изменения и в какие сервисы надо сделать, чтобы добавить скидки по промокоду?
Как минимум надо:
Источниками изменений в сервисе могут быть несколько бизнес процессов — выбор и оформление, оплата и биллинг, доставка. Каждая из проблемных областей имеет свои ограничения, инварианты и требования для заказа. В результате, получается, что в сервисе «товар» у нас хранится информация о товаре, о скидках, остатках товара на складах. А в «заказе» хранится логика работы доставщика.
Иными словами, изменение бизнес логики, которая размазана по нескольким сервисам приводит к зависимым изменениям в нескольких сервисах. И при этом в одном сервисе оказывается код, который друг с другом не связан.
Сервисы-хранилища
Кажется, что решить эту проблему можно, если сделать над сервисами-сущностями отдельный “слой” сервис, которые инкапсулируют в себя всю логику. Но обычно это тоже плохо заканчивается. Потому что тогда сервисы-сущности становятся сервисами-хранилищами, т.е. вся бизнес-логика из них вымывается, кроме хранения.
Если данные хранятся в разных базах, на разных машинах, то мы
Кроме сложной разработки такие сервисы становятся сверх критичным и сильно нагруженными — почти при каждом запросе сервиса верхнего уровня приходится делать несколько запросов в разные сервисы-сущности, а значит, правки в них становятся еще более сложными дабы удовлетворять повышенным требованиям надежности и производительности.
Из-за таких сложностей с разработкой и поддержкой сервисов-сущностей в чистом виде паттерн редко встретишь, обычно сервисы-сущности превращаются в один или два центральных “микросервиса-монолита”, которые часто меняются и содержат основную бизнес-логику и россыпи маленьких микросервисов обычно инфраструктурных и небольших, которые редко меняются.
Разделение по проблемным областям
Изменения сами по себе не рождаются, они приходят из какой-то проблемной области. Проблемная область — это область задач, в рамках которой проблемы, требующие изменений в коде, формулируются на одном языке, с использованием одного набора понятий или связанные бизнес-логикой между собой. Соответственно, в рамках одной проблемной области скорее всего будет один набор ограничений, инвариантов, на которые можно положиться при написании кода.
Разделение ответственности сервисов по проблемным областям, а не по сущностям обычно приводит к более поддерживаемой и понятной архитектуре. Проблемные области чаще всего соответствую бизнес-процессам. Для интернет-магазина скорее всего проблемными областями будут «оплата и биллинг», «доставка», «процесс заказа».
Изменений, которые бы затрагивали одновременно несколько проблемных областей меньше, чем изменений, которые бы затрагивали несколько сущностей.
Кроме того, сервисы, разбитые по бизнес процессам, можно в дальнейшем переиспользовать. Например, если рядом с интернет магазином мы захотели сделать еще продажу билетов на самолеты, то мы могли переиспользовать общий сервис «Биллинг и оплата». А не делать еще один похожий, но специфичный для продажи билетов.
Например, мы можем таким образом разделить на сервисы:
Децентрализация данных, обмен простыми объектами имеет свои плюсы, минусы и подводные камни. С одной стороны децентрализация дает возможность автономно разрабатывать и работать нескольким сервисам. С другой стороны, издержки на хранение двух-трех копий данных и на поддержание консистентности в разных системах.
В реально жизни часто встречается что-то среднее. Сервис сущность с минимальным набором атрибутов, который используется всеми сервисами потребителями. И какой-то минимальный слой логики — например, статусная модель, и события в очередь с оповещением всех об изменениях в сущности. При этом сервисы потребители все-равно довольно-таки часто держат у себя “кэш” данных. Делается все возможное, чтобы изменений в такой сервис было как можно меньше, и это в принципе тяжело сделать из-за того, что потребителей очень много.
При это важно понимать, что любое разбиение — как по сущностям, так и по проблемным областям — не серебряная пуля, всегда будут фичи, которые будут требовать зависимых изменений в нескольких сервисах. Просто при одном разбиении таких изменений будет сильно больше, чем при другом. И задача разработки в том, чтобы минимизировать количество зависимых изменений.
Идеально разбиение возможно, только если у тебя два совершенно независимых продукта. В любом бизнесе у тебя все связано со всем, только вопрос в том, насколько сильно связано.
И вопрос в отделении ответственностей и в высоте барьеров для абстракций.
Проектирование API сервиса
Проектирование интерфейсов в рамках сервиса повторяет историю с разбиением на сервисы, только в меньшем масштабе. Изменение интерфейса (а не просто расширение) — это сложно и долго. В сложных приложениях, интерфейс должен быть достаточно универсальный, чтобы не вызывать постоянных изменений, и должен быть достаточно специфичным и конкретным, чтобы не вызывать растекание ответственности и семантики.
Поэтому интерфейсы сервиса нужно проектировать так, чтобы их семантика была устойчивым к изменениям. А это возможно в том случае, если семантика или зона ответственности интерфейса опиралась на ограничения проблемной области.
CRUD-интерфейсы для сервисов со сложной бизнес-логикой
Слишком широкий и неспецифичный интерфейс способствует либо размыванию ответственности, либо чрезмерному усложнению.
Например, CRUD API для сервисов со сложной бизнес-логикой.Такие интерфейсы не инкапсулируют поведение. Они не просто дают возможность бизнес-логике утечь в другие сервисы и размывают ответственность сервиса, они провоцируют растекание бизнес-логики — ограничения, инварианты и методы работы с данными теперь находятся в других сервисах. Сервисы-пользователи интерфейса (API) должны реализовывать логику сами.
Если попытаться, не меняя значительно интерфейс, перенести бизнес-логику в сервис, мы получим слишком универсальный и слишком сложный метод.
Например, есть сервис тикетов. Тикет может быть разных типов. Каждому типу соответствует разный набор полей и немного разная валидация. Также у тикета есть статусная модель — конечный автомат по переходу из одного статуса в другой.
Пусть API будет выглядеть так: методы POST/PATCH/GET, по урлу /api/v1/tickets/
Вот так, можно обновить тикет
В случае, если статусная модель будет зависеть от тикета, тогда возможны конфликты бизнес-логики. Сначала поменять статус по старой статусной модели, а потом изменить тип тикета. Или наоборот?
Получается, что внутри API-метода будет код, который не связан друг с другом — изменение полей сущности, список доступных полей, в зависимости от типа тикета, и статусная модель. Они меняются по разным причинам и есть смысл их разносить по разным API-методам и интерфейсам.
Если изменение какого-то поля в рамках CRUD-методов API — это не просто изменение данных, а операция, завязанная на согласованное изменение состояния сущности, то эту операцию нужно выносить в отдельный метод и не давать напрямую менять. Если изменение API без обратной совместимости очень плохо (для публичных API), то лучше сразу про это подумать при проектировании API.
Поэтому дабы избежать таких проблем, лучше делать интерфейсы небольшими, специфичными и максимально проблемно ориентированными, вместо универсальных дата-центричных.
Этот (анти)паттерн чаще характерен для RESTful интерфейсов, из-за того, что в нем по умолчанию есть всего несколько дата-центричных “глаголов”-действий создать, удалить, обновить, прочитать. Специфичных для бизнеса операций над сущностями — нет
Что можно сделать, чтобы сделать RESTful более проблемно-ориентированным?
Во-первых, можно добавить методы к сущностям. Интерфейс становится менее restful. Но такая возможность есть. Мы все-таки не за чистоту расы боремся, а решаем практические задачи
Вместо универсального ресурса /api/v1/tickets.json добавить еще ресурсы:
/api/v1/tickets/
/api/v1/tickets/
Во-вторых, можно представить любую операцию, как ресурс в рамках REST. Есть операция миграция тикета из одного типа в другой (или из одного проекта в другой?). Ок, значит будет ресурс
/api/v1/tickets/migration.json
Есть бизнес операция создать триальную подписку?
/api/v1/subscriptions/trial.json
Есть операция перевод денег?
/api/v1/money_transfers.json
Антипаттерн с дата-центричным API на самом деле относится к rpc взаимодействию в том числе. Например, наличие слишком общих методов типа editAccount(), или editTicket(). “Изменить объект” не несет смысловой нагрузки, связанной с проблемной областью. Это значит, что этот метод будут вызывать по разным причинам, по разным причинам менять.
Надо заметить, что data-centric интерфейсы вполне себе ок, если проблемная область предполагает только хранение, получение и изменение данных.
Событийная модель
Одним из способов развязать куски кода может служить организация взаимодействия между сервисами через очередь сообщений.
Например, если в сервисе при регистрации пользователя нам нужно отправить ему welcome-письмо, создать заявку в CRM на клиентского менеджера и т.д, то логично сделать не через явный вызов внешних сервисов, а в сервисе регистрации положить в очередь сообщение “пользователь 123 зарегистрирован”, а все нужные сервисы прочитают это сообщения и совершат необходимое действие. При этом изменение бизнес-логики не потребует менять сервис регистраций.
Чаще всего кидают в очередь не просто сообщения, а события. Поскольку очередь — это лишь транспортный протокол, то на интерфейс данных, распространяются те же самые ограничения, что и на обычный синхронный интерфейс. Поэтому дабы избежать проблем с изменением интерфейса и последующими правками в других сервисах, лучше всего делать события максимально проблемно ориентированными. Еще такие события часто называют событиями предметной области. При этом использование событийной модели обычно не сильно влияет на то, по каким границам бьются (микро)сервисы.
Поскольку события предметной области практически 1 в 1 транслируются в синхронные API методы, то иногда даже предлагают вместо вызовов API использовать поток событий вместо потока вызовов (Event Sourcing). По потоку событий всегда можно восстановить состояние объектов, но при этом еще и иметь забесплатно историю. По факту, обычно такой подход не очень гибок — надо поддерживать все события, и зачастую проще вести историю рядом обычным API.
Микросервисы и производительность. CQRS
В принципе, проблемная область предполагает изменения в коде, связанные не только с функциональными бизнес-требованиями, но и с нефункциональными — например, производительность. Если есть два куска кода с разными требования по производительности, то это значит, что эти два куска кода возможно имеет смысл разделить. И обычно разделяют на отдельные сервисы, чтобы иметь возможность использовать разные языки и технологии, более подходящими под задачу.
Например, есть cpu-bound метод калькулятор в сервисе, написанном на PHP, выполняющий сложные расчеты. С ростом нагрузки и количества данных он перестал справляться. И конечно же как один из вариантов, имеет смысл делать вычисления не в php коде, а в отдельном высокопроизводительном си-шном демоне.
Как один из примеров деления по сервисов по принципу производительности — разделение сервисов на читающих и изменяющих (CQRS). Такое разделение часто предлагают потому, что требования к производительности у читающих сервисов и пишущих разные. Нагрузка на чтение зачастую на порядок выше, чем на запись. И требования к скорости ответа запросов на чтение, намного выше, чем на запись.
Клиент 99% процентов времени проводит в поисках товара, и лишь 1% времени в процессе заказа. Для клиента в состоянии поиска важна скорость отображения, и фичи, связанные с фильтрам, различными варианты отображения товара и т.д. Поэтому имеет смысл выделить отдельный сервис, который отвечает за поиск, фильтрацию и отображение товаров. Такой сервис скорее всего будет работать на каком-нибудь ELK, документоориентированной БД с денормализованными данными.
Очевидно, что наивное разделение на читающие и изменяющие сервисы может не всегда быть хорошо.
Пример. Для менеджера, который работает с наполнением товарной номенклатуры, главными фичами будут возможность удобно добавлять товар, удалять, менять и просматривать. Нагрузки немного, если разделить в отдельные сервисы чтение и изменение, мы от такого разделения ничего не получим, кроме проблем, когда придется делать в сервисах согласованные изменения.
Архитектурные решения и моделирование данных для хранилищ и витрин данных
Константин Лисянский, архитектор хранилищ данных линии программных продуктов DiasoftMIS
Хранилища данных уже не являются экзотикой в России. Стабилизация экономики ведет к росту конкуренции и повышению важности принятия правильных решений для успешной работы предприятий. Многие компании проводят оценку возможности построения централизованного хранилища данных для создания аналитических приложений, некоторые уже инициировали такие проекты. В силу того, что технологии хранилищ данных являются для России достаточно новыми, литература по данной тематике на русском языке встречается редко. Данная статья, не претендуя на полноту изложения материала, является попыткой восполнить этот пробел.
Статья обобщает теоретические знания и практический опыт автора в построении архитектуры и информационных моделей хранилищ и витрин данных. Она описывает особенности моделирования хранилищ и витрин данных по сравнению с моделированием традиционных систем. Делается упор на моделирование времени в хранилищах и витринах данных, описываются общепринятые приемы моделирования.
Основные отличия систем поддержки принятия решений от традиционных оперативных систем
Основные отличия между традиционными оператив ными информационными системами и системами поддер жки принятия решений (СППР) вытекают из отличий в постановке задач, для решения которых создаются системы — обеспечение ежедневной работы предприятия одной системой, и поддержка принятия решений — другой.
На данный момент существует масса публикаций, в которых эти отличия рассматриваются весьма подробно [4, 6, 8]. Такой анализ выходит за рамки данной статьи, по этому мы ограничимся отличиями, влияющими на приемы моделирования тех и других систем.
В силу различной природы систем, требуются различ ные приемы моделирования данных. Мы рассмотрим эти приёмы ниже. Однако перед тем как перейти к приёмам, стоит уделить внимание вариантам архитектуры систем поддержки принятия решений.
Варианты архитектуры СППР
На сегодняшний день известно несколько способов построения СППР. Большинство из них основано на технологиях хранилищ и витрин данных. Остановимся на некоторых из них.
Функциональная СППР
Функциональная СППР (рис.1) является наиболее простой с архитектурной точки зрения. Такие системы часто встречаются на практике, в особенности в организациях с невысоким уровнем аналитической культуры и недостаточно развитой информационной инфраструктурой.
Характерной чертой функциональной СППР является то, что анализ осуществляется с использованием данных из оперативных систем.
Модель данных оперативной системы
Модель данных хранилища данных
Данные поддерживают оперативные процессы, базовые запросы и принятие простейших решений.
Данные поддерживают исторические запросы, анализ тенденций и принятие стратегических решений.
Модель ориентирована на приложение.
Модель ориентирована на предметную область.
Может содержать разрозненные данные и домены из-за унаследованных баз данных и приложений.
Единое согласованное на уровне предприятия определение данных и общие домены данных.
Полная нормализация для контроля целостности данных.
Контролируемая денормализация для эффективного извлечения данных.
Текущие значения данных.
Данные с полной или частичной историей изменений.
Минимальное количество производных данных.
Базовые и суммарные данные.
Содержит все оперативные данные, требующиеся в данный момент.
Содержит данные, имеющие ценность во времени.
Содержит данные, произведенные, в основном, в пределах предприятия.
Содержит внутренние данные предприятия, а так же полезные внешние данные, помогающие проводить анализ тенденций, например, демографические и экономические данные.
СППР с использованием независимых витрин данных
Независимые витрины данных (рис.2) часто появляются в организации исторически и встречаются в крупных организациях с большим количеством независимых подразделений, зачастую имеющих свои собственные отделы информационных технологий.
СППР на основе двухуровнего хранилища данных
Двухуровневое хранилище данных (рис.3) строится централизовано для предоставления информации в рам ках компании. Для поддержки такой архитектуры необхо дима выделенная команда профессионалов в области хра нилищ данных.
Это означает, что вся организация должна согласовать все определения и процессы преобразования данных.
СППР на основе трехуровневого хранилища данных
Хранилище данных (рис. 4) представляет собой единый централизованный источник корпоративной информации. Витрины данных представляют подмножества данных из хранилища, организованные для решения задач отдельных подразделений компании. Конечные пользователи имеют возможность доступа к детальным данным хранилища, в случае если данных в витрине недостаточно, а также для получения более полной картины состояния бизнеса.
Мы рассмотрели основные варианты приведённых выше типов архитектур систем поддержки принятия ре шений. Выбор конкретного варианта зависит от условий, в которые поставлена проектная группа. Нужен ли быстрый возврат от инвестиций, или можно потратить больше времени и построить надежную инфраструктуру? Является ли проектная группа профессиональной или состоит из новичков? Существует ли формализованная методология или механизмы работы еще не отлажены? Ответы на эти и ряд других вопросов могут повлиять на ваш выбор.
Подробное описание преимуществ и недостатков каждого варианта архитектуры можно найти в литературе [2, 3].
Моделирование хранилищ данных
В силу коренных отличий хранилищ данных от опе ративных систем приемы моделирования также отли чаются. Все описанные ниже особенности и приемы модели рования относятся к моделированию для реляционных баз данных. Приемы моделирования для многомерных баздан ных выходят за рамки данной статьи.
Особенности моделирования времени в хранилищах данных
Традиционные подходы основываются исключительно на моделировании статического представления реального мира. При этом если время и принимается в расчет, то только в виде временных отметок создания записей и их модификации. С точки зрения моделирования времени хранилища данных принципиально отличаются от оперативных систем. Модели хранилищ данных интенсивно используют временные отметки.
На данный момент известны три основных способа моделирования времени в хранилищах данных. Рассмотрим каждый из них по отдельности.
Модель снимков данных
Снимок данных — это представление данных в опре деленный момент времени. Данная модель характерна для оперативных систем (OLTP). Обновления данных носят деструктивный характер, то есть предыдущие значения атрибутов замещаются новыми (рис. 5). Модель имеет достаточно ограниченный круг применения в хранилищах данных, поскольку не обеспечивает хранения истории изменений.
Событийная модель
Событийная модель (рис. 6) используется для модели рования данных о наступлении событий в определенные моменты времени. Данная модель хорошо подходит для моделирования транзакций, таких как: продажи, финансовые транзакции, складские операции и т.д.
Статусная модель
Статусная модель используется для моделирования состояния объектов во времени. Она хорошо подходит для представления данных, имеющий нетранзакционный характер.
Статусная и событийная модели являются взаимно дополняющими. Путем преобразований из одной можно получить другую. Например, зная остаток на счете на определенный момент и историю транзакций в событийной модели, можно восстановить все статусы счета (остатки на счете) в периоды между транзакциями. И наоборот, имея статусную модель остатков на счете, можно вычислить события (т.е. транзакции), которые происходили со счетом в начале (конце) каждого периода.
Выбор ключей
Выбор ключей для таблиц хранилища данных является непростой задачей. Перед разработчиком модели хранилища встает вопрос: использовать ли в хранилище данных ключи из оперативных систем, и если нет, то — как их сформировать? Рассмотрим варианты решения этой задачи.
Использованиеключей из оперативных систем
Данное решение представляет ся очевидным, однако практика показывает, что это далеко не самое удачное решение. Одна из проблем при использовании ключей из оперативных систем заключается в том, что некоторые приложения повторно используют ключи, что может очень сильно затруднить поддержку хранилища. При большом количестве источников данных есть вероятность совпадения ключей в записях из разных источников.
Генерация ключей
Одно из решений проблемы выбора ключей для таблиц хранилища данных заключается в генерации новых ключей для записей, загружаемых из систем источников.
Вопросы целостности данных
Ввиду историчности данных, их целостность в храни лище носит характер, отличный от целостности данных в оперативных системах. Если при построении транзакци онных систем речь идет о целостности транзакций и со блюдении ссылочной целостности, то в хранилищах дан ных кроме этого очень важно обеспечивать историческую целостность данных и соблюдение бизнес-правил, которые могут выражаться механизмами, отличными от ссылочной целостности.
Соответственно, ссылочная целостность и непротиворечивость данных в хранилище данных организуется иначе. Как правило, при проектировании хранилищ данных не используются триггеры и встроенные в СУБД механизмы контроля целостности. Они способны очень сильно снизить производительность системы и увеличить окно загрузки (что, как правило, крайне нежелательно). Вместо этого целостность данных контролируется на этапе их загрузки путем выполнения различных проверок.
Моделирование витрин данных
Приемы моделирования витрин данных отличаются от приемов моделирования хранилищ данных в силу различных требований к структурам данных. Если основной за дачей хранилища данных является хранение консолидированной исторической информации, то витрина данных строится с учетом требований по доступу к данным и представления информации.
Как правило, для моделирования витрин данных используются типы модели под названием: схема «звезда» и схема «снежинка». Остановимся подробнее на каждом из этих типов моделей.
Схема «звезда»
Схема «звезда» — популярный тип модели данных для витрин данных. Данная модель характеризуется наличием таблицы фактов, окруженной связанными с ней таблицами размерностей. Запросы к такой структуре включают простые объединения таблицы фактов с каждой из таблиц размерностей. Характеризуется высокой производительностью запросов.
Проектируется для выполнения аналитических запросов. Характеризуется небольшой избыточностью данных и высокой по сравнению с нормализованными структурами производительностью. Некоторые промышленные СУБД и инструменты класса OLAP/Reporting умеют использовать преимущества схемы «звезда» для сокращения времени выполнения запросов.
На рисунке (рис.8) изображен пример схемы «звезда» для анализа остатков на счетах и количества транзакций в разрезе времени, клиентов, счетов, продуктов, отделений, статусов счетов. Данная модель позволяет ответить на широкий спектр аналитических вопросов.
Давайте рассмотрим компоненты схемы «звезда».
В технологии многомерного моде лирования размер ность — это аспект, в разрезе которого можно получать, фильтровать, группировать и отображать информацию о фактах.
Размерности, как правило, имеют многоуровневую иерархическую структуру. Например, размерность ВРЕМЯ может иметь следующую структуру: ГОД КВАРТАЛ МЕСЯЦ ДЕНЬ
Факты — это величины, обычно числовые, хранящиеся в таблице фактов и являющиеся предметом анализа. Примеры фактов: объем операций, количество проданных единиц товара и т.д.
Факты имеют ряд свойств, на которых мы вкратце остановимся. Более подробное описание фактов и их свойств можно найти в литературе [1, 8, 9].
Аддитивность определяет возможность суммирования факта вдоль определенной размерности.
Аддитивные факты можно суммировать и группировать вдоль всех размерностей на любых уровнях иерархии.
Полуаддитивный факт — это факт, который можно сум мировать вдоль определённых размерностей, и нельзя — вдоль других. Примером может служить остаток на счете (или остаток товара на складе). Данную величину нельзя суммировать вдоль размерности ВРЕМЯ. Однако сумма остатков по счетам вдоль размерности смысл для анализа.
Неаддитивные факты вообще нельзя суммировать. Пример неаддитивного факта — отношение (например, выраженное в процентах).
Специалисты рекомендуют моделировать полуаддитивные факты таким образом, чтобы сделать их более аддитивными. Например, представить процент составляющими его величинами [1].
Таблицы покрытия используются с целью моделиро вания сочетания размерностей, для которых отсутству ют факты. Например, нужно найти количество категорий продуктов, которые сегодня ни разу не продавались. Таб лица фактов продаж не может ответить на данный воп рос, поскольку она регистрирует только факты продаж. Для того чтобы модель позволяла отвечать на подобные вопросы, нужна дополнительная таблица фактов (кото рая, по сути дела, не содержит фактов), которая и назы вается таблицей покрытия.
Схема «снежинка»
Данная схема (рис.9) используется для нормализации схемы «звезда». Она несколько сокращает избыточность в таблицах размерностей. Одним из достоинств является бо лее быстрое выполнение запросов о структуре размерностей (запросы вида «выбрать все строки из таблицы размерности на определенном уровне»), которые очень часто выполняют ся при анализе данных, и могут задерживать ход анализа.
Однако основным достоинством схемы «снежинка» является не экономия дискового пространства, а возможность иметь таблицы фактов с разным уровнем детализации. Например, фактические данные на уровне дня, а плановые — на уровне месяца.
Моделирование времени в витринах данных
Витрины данных, как правило, характеризуются нали чием явной размерности ВРЕМЯ. При этом структура данной размерности может меняться в зависимости от моделируемой предметной области и требований, предъявляемых пользователями к представлению времени.
Моделирование времени в витринах данных — достаточно сложный момент, освещение которого заслуживает отдельной статьи, мы же перейдем к выбору инструментов для моделирования.
Критерии, определяющие выбор инструментов для моделирования
Для создания и поддержки успешных моделей хранилищ и витрин данных необходимы соответствующие средства моделирования. В настоящее время на рынке присутствует достаточно большое количество поставщиков программных продуктов данного класса.
Проектирование хранилищ и витрин данных — инте ресный и достаточно трудоемкий процесс, требующий использования приемов и методик, отличных от техноло гических принципов, применяемых при проектировании оперативных информационных систем. Данная тема будет продолжена в последующих статьях.
Литература
1. Adamson, C., Venerable, M., «Data Warehouse Design Solutions». John Wiley & Sons, Inc (1998). ISBN 047125195X.
2. Devlin, B., «Data warehouse: from architecture to implementation». Addison Wesley Longman, Inc. (1997). ISBN 0201964252.
3. IBM, «Business Intelligence Architecture on S/390. Presentation Guide». SG24574700, IBM Corporation (2000).
4. IBM, «Business Intelligence Certification Guide». SG24574700, IBM Corporation(2000).
5. IBM, «Data Modeling Techniques for Data Warehousing». SG24223800, IBM Corporation (1998).
6. Inmon, W., «What is a data warehouse?» White Paper.
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 0471153370.
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 0471255475.
10. 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 0471153672.
11. Winsberg, P., «Modeling the Data Warehouse and Data Mart». InfoDB, 10, No 3, 110