Модели данных для телекоммуникационных компаний

Введение

На российском телекоммуникационном рынке компании, предоставляющие телекоммуникационные услуги, можно условно подразделить на три типа:

• компании, обеспечивающие междугородную и международную связь (ОАО "Ростелеком", ОАО "МТТ");
• операторы, предоставляющие в основном услуги фиксированной связи (межрегиональные компании связи (МРК), входящие в структуру ОАО "Связьинвест");
• операторы мобильной связи (ОАО "Вымпелком", ОАО "МТС", ОАО "Мегафон" и др.).

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

Ускорить доступ, повысить качество

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

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

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

В данной статье мы поделимся опытом практического применения модели данных, разработанной корпорацией IBM для компаний, предоставляющих услуги связи, -IBM Telecommunications Data Warehouse (TDW) на проекте по построению хранилища данных  в телекоммуникационной компании.

Единая бизнес-модель

IBM TDW  представляет собой совокупность бизнес-понятий, взаимоувязанных между собой в единую бизнес-модель. Ее применение позволяет упорядочить и более взвешенно управлять бизнес-требованиями функционального заказчика к будущей аналитической системе и "укладывать" их в физическую структуру базы данных хранилища. Как и любая другая модель, IBM TDW,- это звено между предъявляемыми бизнес-требованиями заказчика, структурой будущего хранилища данных и существующими в компаниями информационными системами (источниками данных для хранилища).

Модель данных TDW  включает следующие три уровня: модель данных (Telecommunications Services Data Model - TSDM), модель хранилища (Telecommunications Data Warehouse Model - TDWM) и шаблоны бизнес-решений (TDW Business Solution Templates, TBSTs). Рассмотрим их более подробно.

1. TSDM является информационной структурой компании. Данный уровень это настраиваемая иерархия бизнес-понятий и определений, обеспечивающая прямую связь между аналитическими требованиями, моделью данных и запросами компании-оператора.
2. TDWM представляет собой обобщенные и нормализованные диаграммы "сущность - связь" всей компании для множества решений по управлению данными в сфере телекоммуникаций. Включая более 800 сущностей и 3000 атрибутов, она образует подробную модель хранилища данных.
3. TBSTs содержит около 40 шаблонов, отражающих методики построения отчетов и сгруппированных по области отчетности. По своей сути данный уровень является набором витрин данных.

От общего к частному

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

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

Особенности применения IBM TDW

Практика использования модели IBM TDW на одном из проектов, показывает, что оно имеет ряд особенностей:

• модель IBM TDW - это консолидированный опыт многих специалистов, поэтому в ней сосредоточены лучшие решения (best practice), из которых можно почерпнуть новые идеи для проведения более разностороннего анализа бизнеса;
• бизнес-консультант, впрочем, как и IT-специалист, не работавший в телекоммуникационной сфере и не занимающий ключевой роли на проекте, после ознакомления с данной моделью, гораздо легче проводит анализ бизнес-потребностей заказчика, поскольку ему известно, какими сущностями и понятиями оперирует бизнес. Это в итоге обеспечивает повышение качества процесса сбора требований. У консультанта после изучения модели возникают более обоснованные вопросы к функциональному заказчику;
• консолидированный опыт и результаты многих проектов, реализованных специалистами компании IBM, которые заложены в модель данных, обеспечивают реализацию правила "80 на 20". В частности данное правило было соблюдено для набора сущностей в хранилищах данных (80% сущностей были взяты из преднастроенной модели, 20% были добавлены). В то же время о составе атрибутов в выбранных сущностях этого сказать нельзя: примерно 70% атрибутов были добавлены или отредактированы. Такая значительная корректировка атрибутивного состава объясняется особенностями ведения бизнеса;
• средство визуализации и корректировки модели IBM M1 предназначено исключительно для решения узкоспециализированной задачи - моделирования бизнес-требований и не позволяет в едином интерфейсе поддерживать логическую и физическую структуры будущего хранилищ данных. Но компания IBM разработала новое решение - IBM Rationale Data Architecture, которое обещает быть более адаптировано под все задачи разработки модели (сбор и моделирование бизнес-требований, моделирование логического и физического уровней модели, проектирование витрин данных и др.), что делает возможным более гармоничную интеграцию средства управления моделью данных в общую функциональную архитектуру хранилища;
• предлагаемая третья форма нормализации физического уровня модели данных не является оптимальной для организации хранилища в телекоммуникационных компаниях из-за большого объема данных, что привело к необходимости проведения денормализации при разработке целевой модели данных;
• представленный в IBM TDW набор витрин данных (область TBST) не был использован на проекте. Это обусловлено большим количеством изменений состава атрибутов исходной модели, после чего было уже проще проектировать витрины данных "с нуля".

Факторы успеха

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

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

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

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