Skip to Content

Проектирование процессов перегрузок данных

Автор(ы): 
Сергей Коломиец

Часть 1

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

С одной стороны, по мнению некоторых авторитетных специалистов, проблема перегрузки данных решена и нет необходимости поднимать её заново. С другой стороны, учитывая высокий уровень неудачных проектов при разработках ХД (в которых процессы перегрузки занимают до 70% трудозатрат), можно констатировать факт, что в настоящее время требования к подобным операциям изменились качественно, а так же возросла потребность в эффективных методах их проектирования и разработки [1, 2, 3].

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

В свою очередь, необходимость работы с технологией OLAP и многомерной моделью определяет потребность в проведении новых, специфических трансформаций данных, которые извлекаются из «стандартных» транзакционных систем и формирует новые требования к качеству информации [7, 8].

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

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

Нечто похожее происходит и с процессами перегрузок данных. Просто реализовать разовую перегрузку уже недостаточно. Её надо сопровождать, (следовательно, уметь быстро ориентироваться в алгоритме заданного процесса даже через длительное время), уметь разрабатывать её командой разработчиков (следовательно, иметь доступные структурные и методические решения стандартных задач), контролировать качество данных, иметь формализованные процедуры автоматизации повышения качества. Принимая во внимание вышесказанное, в свете применения технологий OLAP, как организационной среды, как фундамента существования и развития информационной структуры предприятия, последняя может выглядеть так, как изображено на Рис. 1.

Функциональная схема потоков данных при эксплуатации хранилища данных (ХД)
Рис. 1. Функциональная схема потоков данных при эксплуатации хранилища данных (ХД)
 

Не вдаваясь в подробный анализ достоинств и недостатков подобной организации информационной структуры, отметим, лишь, что, в случае применения технологий OLAP, операции перегрузок имеют первостепенное значение. А при грамотной организации сопровождении, позволяют достигать небывалой гибкости и управляемости информационной структуры предприятия, которая при ныне сложившейся «классической» её организации, страдает инертностью и высокими рисками процессов изменения. В частности, процедуры замены (и развития) отдельных OLTP-систем проходят практически безболезненно, особенно, если в интерфейс перегрузки данных не вносится больших изменений. Здесь следует отметить очевидный факт: изменение (развитие) оперативной системы обычно не влечёт кардинального изменения в составе и структуре элементов данных, с которыми работает эта система [12]. Другими словами, реальные события не происходят по иным законам в зависимости от того, в какой транзакционной системе они регистрируются. Развитие (если оно правильное), характеризуется наследованием.

Грамотной организацией и сопровождением процессов перегрузки данных обеспечивается более гибкий и эффективный учёт этапности развития, изменения количества как оперативных систем, непосредственно, так и степени наполнения самого хранилища данных. Стоит отметить, что гибкость является особенно важным преимуществом подобных систем, учитывая неизбежность постоянных изменений и современные представления о роли информационных систем в экономическом развитии компании [14].

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

Следует отметить, что усилия в направлении создания формализованных процедур проектирования и разработки прилагаются давно. Есть даже некоторые результаты, по которым, тем не менее, можно сделать вывод, что до завершения создания универсальной промышленной технологии перегрузок ещё далеко. [9, 10, 11].

В настоящее время явно не хватает информации о том, как правильно разрабатывать и как правильно проектировать подобные процессы. Более того, на рынке всё больше появляется специальных продуктов для «эффективной разработки» процессов перегрузок, разработчики которых просто подменяют эффективность разработки, эксплуатации и сопровождения скоростью самого процесса перегрузки. К сожалению, подобные продукты не заключают в себе никакой формализованной технологии, но лишь предлагают пользователю графическую оболочку для визуальной разработки процессов перегрузки и (в большинстве случаев), содержат утилиты доступа к различным источникам данных. На первый взгляд – немало! Однако, основные проблемы лежат гораздо глубже.

Казалось бы - парадокс, но никто не сообщает пользователю, как именно должны быть организованны те процессы, которые «так легко» можно разработать с помощью визуального средства? Какую именно информацию стоит поддерживать в системе метаданных, чтобы эффективно эксплуатировать и сопровождать ХД? В условиях, когда стандарт на обмен метаданными между приложениями практически не развивается, поддержание их в адекватном состоянии – это чистые эксплуатационные расходы. [9, 10, 11] Ручной труд. В этой ситуации вполне обоснован вопрос: чем определяется минимально необходимый объём метаданных, требуемый для поддержания ХД? Так же обоснованным, с точки зрения управления проектом создания ХД, выглядит вопрос о том, какие условия необходимо иметь в виду при проектировании информационной модели БД хранилища данных, учитывая технологические потребности операций перегрузки. Это необходимо знать уже во время проектирования, а не выяснять в процессе разработки процедур загрузки данных.

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

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

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

Источник данных

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

Одним из основных таких понятий является понятие «Источник данных».Что следует считать источником данных, говоря об оптимальности организации процесса перегрузки данных? Отдельную реляционную таблицу (структурированный файл) или совокупность таблиц (файлов) OLTP-системы, объединённых по некоторому принципу? Если объединённых, то по какому принципу?

Чтобы ответить на эти вопросы сформулируем первую рабочую гипотезу: «Любую информацию, хранящуюся в реляционной модели данных (допустим, в третьей нормальной форме), можно без потерь преобразовать к многомерной модели данных». (А ту информацию, что не в «третьей форме», приводим к ней и преобразуем без потерь к «многомерной».) Естественно, что без экскурса в реляционную алгебру нельзя строго доказать или опровергнуть эту гипотезу. Ограничимся лишь логической демонстрацией наших предположений.

Если модель реляционная, значит там есть сущности и связи между ними. Сущности - это некоторые объекты предметной области (естественные тела), характеризующиеся соответствующими атрибутами [4]. Обычно сущность моделируются одной или несколькими связанными таблицами. Однако, если модель правильная и концептуальное соответствие «сущность-атрибут» не нарушается, мы всегда можем его «восстановить» и разместить в другой модели. (см. Рис. 2) Осталось уточнить требование правильности, чтоб преобразования были без потерь. На первый взгляд, условия третьей нормальной формы – достаточно, а точный ответ таиться в глубинах математики и нырять за ним мы не будем. Тем более, что на практике он не очень нужен, т.к. работать приходится с реальными источниками, которые ранее проектируются кем-то другим. Если же в практической деятельности возникает проблема «преобразования с потерями», распознать которую можно нахождением хотя бы одного примера такой «потери», решение лежит, обычно, в организационной, а не технической области.

Отношения между реляционной и многомерной моделью
Рис. 2. Отношения между реляционной и многомерной моделью
 

Подобное же объяснение истинности требуемой гипотезы можно дать, используя понятие элемента данных, которое содержится в соответствующем стандарте ISO [12].

Так же как и реляционные, многомерные модели тоже бывают разные [2,13]. В частности, одна многомерная модель может отличаться от другой количеством измерений. Здесь мы тоже сталкиваемся с практической ситуацией, когда количество измерений модели определяет кто-то другой: тот, кто моделирует аналитическую систему исходя из потребностей пользователя.

Естественно, что (в соответствии с известным законом Мерфи: если что-нибудь может случиться - оно случается) когда-нибудь обязательно возникнет ситуация, когда «восстановленной» из ранее созданной (legaсy) реляционной модели информации обязательно будет не хватать одного-двух измерений, чтобы полностью соответствовать действующим аналитическим потребностям, «запечатлённым» в виде многомерной модели данных. В такой ситуации, потребуется использование второй рабочей гипотезы: «Добавить дополнительное измерение к уже существующей многомерной модели данных можно при помощи дополнительной таблицы согласования измерений (классификатора, справочника)». Таблица согласования измерений содержит соответствие ключа какого-нибудь одного (или сочетанию ключей каких-нибудь нескольких) из существующих измерений ключу добавляемой размерности.

Например, информация о фактических значениях определённого показателя по покупателю может быть восстановлена из реляционной модели OLTP-системы в следующих измерениях: времени; отрасли промышленности; кода подразделения, ответственного за взаимоотношения с покупателем; уникального идентификатора, автоматически созданного внутри транзакционной системы и т.д. В случае, если для аналитика требуется ещё и уникальный идентификатор покупателя, «созданный внутри налоговой системы» (другими словами ИНН), мы будем вынуждены искать (или создавать) таблицу согласования, которая должна содержать соответствие уникального ключа покупателя из транзакционной системы, уникальному ключу покупателя из «налоговой системы». Таким образом, мы получаем возможность рассмотреть информацию в новом измерении, которое не предусмотрено в ранее созданной реляционной модели. Похожая ситуация возникает при согласовании данных о покупателях из различных оперативных систем.

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

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

Совокупность линейных и иерархических справочников, содержащих информацию непосредственно для представления основных размерностей многомерных моделей, используемых в ХД, будем называть стандартным набором измерений, и обозначать SCF (от Standard Classifier). Обычно такие справочники общедоступны и пользователь не имеет возможности (и необходимости) их изменять. Например, общероссийский классификатор отраслей народного хозяйства никогда не требуется изменять. Он является «объективной реальностью», основным измерением фактической информации, его не надо изменять, его надо учитывать. Если он измениться, то не по решению пользователя, и остаётся только надеяться, что это решение будет учитывать принципы наследования или хотя бы функциональности (однозначности) трансформации.

Функциональная схема потоков данных при эксплуатации ХД с учётом дополнительных источников данных
Рис. 3. Функциональная схема потоков данных при эксплуатации ХД с учётом дополнительных источников данных
 

Справочники UCF и SCF типов, обычно называют ссылочными наборами данных и обозначают RDS (Referenсе Data Sets). Подобные наборы данных нуждаются в специфическом сопровождении и организации доступа к ним, чему в настоящее время не уделяется должного внимания. Однако, правильная организация сопровождения и эксплуатации RDS будет иметь всё большее значение с развитием технологий хранилищ данных. [15]. С учетом приведённых определений, можно более подробно представить себе структуру информационной системы предприятия, изображённую на Рис. 3.

Особенным видом справочной информации являются справочники, получаемые из оперативной системы. По своему характеру они близки к справочникам (могут формировать измерения), но изменяются средствами оперативной системы. Как разработчик решил, так и будет. На это влиять не возможно. Для таких источников будем использовать аббревиатуру DCF (Danamic classifier). Процедура обработки таких справочников подразумевает специальные механизмы замены ключей, которые ориентированы на поддержание целостности данных в хранилище независимо от изменений в оперативных системах.

Завершая первую из цикла статей о проблемах проектирования и разработки процессов перегрузки данных, необходимо отметить, что, во-первых: многие понятия и определения, приводимые в цикле, являются оригинальными и часто не имеют аналогов в литературе по ХД. Во-вторых: в цикле статей отражается представление о технологии проектирования, сложившееся на основе практического опыта разработки и внедрения ХД производственным центром Datagy, компании «Диасофт».

Литература

  1. Саймон А. Р. Стратегические технологии баз данных: менеджмент на 2000 год. /Пер с англ. – М: Финансы и статистика, 1999. – 479 с.
  2. W. Inmon. Building The Data Warehouse. - Wellesley, MA Publising Group 1993.
  3. R. Kimball, et al. The Data Warehouse Lifecycle Toolkit : Expert Methods for Designing, Developing, and Deploying Data Warehouses. - Willey, 1999.
  4. В.И. Вернадский. Научная мысль, как планетарное явление. – М. Наука, 1991, 251 с.
  5. CIO Enterprise Magazine (http://www.cio.com)
  6. ???
  7. IBM Enterprise Architecture Planning.
  8. Massachusetts Resarch For Data Quality.
  9. http://www.cwmforum.org
  10. http://www.omg.org/technology/
  11. http://www.oasis-open.org
  12. ISO 11179 Information Technology - Basic Data Element Attributes.
  13. http://www.olap.ru
  14. М.Хаммер, Дж.Чемпи. Реинжиниринг корпорации: манифест революции в бизнесе. /Пер с англ. Издательство С.-Петербургского университета, 1997.
  15. M. Chisholm. Managing Reference Data in Enterprise Databases: Binding Corporate Data to the Wider World – Morgan Kaufman Publishers, 2001

См. Часть 2