Маппинг это в бизнесе

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

114 просмотров

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

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

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

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

Impact Mapping: планирование разработки продукта с учетом бизнес целей (Александр Бындю) — TK Conf

Вы должны четко понимать, когда происходит продажа

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

• Стоит ли рискуя жизнью ждать до последнего самку утконоса
• Обоснованно ли существование на корабле четырех слонов и одной слонихи?
• Есть ли смысл пересчитывать всех змей и тараканов или проще забить? А еды вообще хватит?
• И — ого, похоже, на борту самка гиены, надо не забыть поселить её подальше от антилоп…

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

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

Стратегия раннего и последовательного внедрения событий поможет вам напрямую или косвенно справиться с такими ужасами как:

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

Базовые принципы маппинга (настройки custom events)

Что такое User Story Mapping за 3 минуты

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

Примеры:
registration_start -> registration_ok
dating_start -> dating_new_chat_ok
cart_start -> cart_ok

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

Примеры:
registrations_men — все мужские регистрации
registrations_women — все женские регистрации
profile_unfinished — все, бросившие заполнять профайл на любом этапе
purchasers_all — все купившие хоть какой-то товар

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

4. Думайте от бизнеса всегда. Задайте вопросы:

• Приносит ли это деньги?
• Переплачиваю ли я?
• Что мне даст эта фича в деньгах?
• Какие проблемы пользователя должен решать продукт?

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

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

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

8. Не откладывайте на потом. Любой выкладываемый вами в App store функционал заранее должен быть обвешан нужными событиями. За каждый потерянный день, когда вы могли накопить бизнес-данные, вы платите своими деньгами.

9. Делайте качественную документацию продукта ли требуйте ее от вашей команды. Да, мы понимаем, что все ненавидят это занятие. Куда как проще просто поставить разработчику задачку в slack. Но в случае с событиями, беспорядок в документации равен плевку в свой собственный бизнес.

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

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

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

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

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

Иными словами, стоит принять маппинг как неотъемлемую часть продукта, такую же важную как закупка трафика, разработка, продакт менеджмент.

Источник: vc.ru

Data Mapping: лучшие техники и инструменты

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

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

Что такое Data Mapping?

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

Использование маппинга данных позволит вам:

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

После чего вы сможете сделать выводы и выделять ценную информацию.

В чем польза Data Mapping?

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

1. Легко интегрировать, трансформировать и переносить данные, а также создавать хранилища данных (data warehouses).
2. Устанавливать прямую взаимосвязь между вашими данными сразу из нескольких источников.
3. Убедиться в качестве и точности ваших данных. Программное обеспечение для мапирования данных может автоматически отмечать несоответствия данных или выделять те данные, которые не являются качественными или точными.
4. Определять тенденции в реальном времени и делиться отчетами с данными с членами команды легко и эффективно.
5. Убедиться, что вы извлекаете максимальную пользу из своих данных и правильно применяете идеи и знания.
6. Использовать программное обеспечение для маппинга данных, чтобы упростить (и автоматизировать большую часть) сам процесс мапирования данных без кода.

Примеры использования Data Mapping

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

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

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

Совместное использование данных между тремя источниками может выглядеть примерно так:

Техники Data Mapping

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

1. Ручное мапирование данных

Manual Data Mapping требует для работы профессиональных кодировщиков и data mappers. Это IT-специалисты, которые будут кодировать и map (преобразовывать) ваши источники данных. Хотя это трудоемкий процесс, который требует профессиональной помощи, он позволяет вам полностью контролировать и настраивать свои maps.

1. Полуавтоматический маппинг данных

Semi-automated Data Mapping или Schema Mapping требует определенных знаний в области кодирования и означает, что ваша команда будет перемещаться между процессами сопоставления данных вручную и автоматически (отсюда и название этого метода).

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

1. Автоматическая техника мапирования данных

Automated Data Mapping означает, что инструмент позаботится обо всех аспектах процесса мапирования данных за вас. Это делает данный вид технологии идеальным вариантом, если у вас нет своего кодировщика или временно объект не доступен. Этот тип Software обычно позволяет выполнять маппинг данных путем перетаскивания. Вам просто нужно научиться пользоваться инструментом (и заплатить за него).

Инструменты для маппинга данных, которые автоматизируют для вас процесс Data Mapping, рассмотрим далее.

Инструменты для маппинга данных

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

• код не требуется;
• у них часто есть пользовательский интерфейс (UI) с перетаскиванием «drag-and-drop»;
• вы можете внедрить их в своей команде независимо от уровня вашего технического опыта.

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

Цена: Бесплатная 30-дневная пробная версия

Bloomi, принадлежащая Dell, представляет собой iPaaS-решение (облачное и масштабируемое), которое объединяет данные и приложения как в облаке, так и локально. Создавайте облачные интеграции, которые инструмент называет Atoms. Затем вы можете начать передачу данных между облаком и локальными приложениями.

Функция маппинга данных Bloomi переводит для вас электронный обмен данными (EDI или Electronic Data Interchange). Инструмент имеет пользовательский интерфейс с перетаскиванием, который упрощает маппинг данных, а также библиотеку доступных соединителей, чтобы вы могли быстро установить интеграцию.

Цена: Бесплатная 30-дневная пробная версия

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

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

Цена: Бесплатная 14-дневная пробная версия

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

Вы можете использовать инструмент «drag-and-drop» для создания, отладки и управления сложными задачами интеграции данных. Astera также изначально подключается к различным поставщикам баз данных, включая SQL Server, Oracle и DB2.

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

• очистка данных;
• профилирование данных;
• качество данных.

А для повышения точности есть встроенные преобразования, которые:

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

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

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

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

Источник: maddata.agency

Основные аспекты формирования маппинга витрины для миграции

В настоящее время наша команда в Neoflex выполняет работы по реализации нескольких проектов миграции данных, в рамках которых появляется потребность построения маппинга. Наш опыт основан на проекте крупнейшего в России банка по миграции витрин из СУБД Oracle в СУБД PostgreSQL в рамках импортозамещения отечественным ПО.

Перед разбором алгоритма маппирования разберем основные понятия.

Начнем с термина «витрина данных». Это простая форма хранилища данных, которое ориентировано на определенную тему или направление деятельности: продажи, финансы или маркетинг. Источниками данных для витрины могут служить: центральное хранилище, внутренние операционные системы, а также внешние данные. Миграция используется для повышения скорости обращения с данными и построения бизнес-отчетов, повышения уровня безопасности информации в рамках импортозамещения на отечественное ПО и т.д.

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

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

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

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

Также в статье используются понятия «сущность» и «атрибут».

Атрибут — это поле (столбец) таблицы данных, сущность — таблица с атрибутами. Например, в сущности «Клиент» находятся атрибуты «ИНН», «Наименование организации», «Статус действия» и т.д.

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

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

Проведение «ручного» маппирования витрины разделим на этапы:

1. Фиксация витрины и сбор информации о ней;
2. Анализ атрибутного состава;
3. Поиск первоисточников и систем-источник данных;
4. Анализ актуальных источников;
5. Проверка корректности заполнения и согласование маппинга.

Разберем каждый из них.

Первый этап. Фиксация витрины и сбор информации о ней

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

Зачем это необходимо сделать? Частым случаем бывает, что бизнес-заказчик после включения витрины в план миграции проводит по ней доработки или вносит изменения. В результате, не уведомив бизнес-заказчика о начале работы над витриной, высока вероятность «отработать» не актуальный состав витрины. За чей счет будет происходить «переработка» — становится острым вопросом при организации работ на проекте.

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

1. Планируются ли внесения изменений в атрибутный состав витрины или ее логику? Соответственно, можно ли начинать работы по витрине, строить ее маппинг?
2. Какой бизнес-смысл витрины, в чем ее «ценность» для бизнеса?
3. Где расположен актуальный S2T (source to target — преимущественно табличное описание соотнесенных между собой полей источника и витрины, если проще, это маппинг на изначальной БД), прототип и скрипт разработки (попросить ссылку)?
4. Какие должны быть глубина истории, историчность и регламент обновления для витрины в новом источнике? . Так, глубина истории может потребовать привлечения дополнительных источников, следовательно, расширения маппинга, или объемов для хранения, или оптимизации кода.
5. Какая система-источник для витрины?
6. Какие предъявляются требованиях к прототипу, к эталону (для сравнения) и какие необходимо провести тест-кейсы?
7. В каком формате необходимо предоставить итоговый маппинг по витрине (попросить шаблон) ?

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

Второй этап. Анализ атрибутного состава S2T витрины

Особое внимание стоит уделить правилам, нормативам и требованиям, принятым у бизнес-заказчика. Важно уточнить у коллег по проекту/бизнес-заказчиков – какие существуют шаблоны, правила оформления результатов маппирования, основные и обязательные этапы работы на конкретном проекте, предусмотренные инструменты/ПО – все это позволит быстро и результативно, а, главное, корректно составить маппинг витрины.

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

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

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

Например, поле витрины с бизнес-описанием «Тип компании» имеет под собой минимум два значения. Атрибут может содержать информацию о том, является ли компания юридическим, физическим лицом (ИП) или информацию, касающуюся ее организационно-правовой формы (ООО, АО, ЗАО).

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

Третий этап. Поиск первоисточников и систем-источник данных

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

Суть этапа – выявить трек (data lineage), используемый при построении витрины данных до систем-источников.

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

• ER-модели хранилища данных;
• Confluence бизнес-заказчика (при наличии, или иной аналогичный инструмент);
• Informatica (при наличии);
• опрос бизнес-подразделений.

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

Четвертый этап. Анализ актуальных источников

После выявления всех источников и первоисточников для витрины необходимо произвести корректировку плана миграции витрины. На этом этапе необходимо определить актуальные атрибуты для витрины в новой БД. Как правило, для БД существует описание реализованных/запланированных к реализации сущностей – формат представления этих данных может быть любой. Для упрощения понимания описание сущностей и атрибутов в новой БД (модель данных) представим в виде Excel-файла со следующим наполнением:

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

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

При анализе модели данных удобно идти как от общего к частному, так и от частного к общему.

В первом случае выбираем основное поле в витрине, например, «ИНН». Находим по бизнес-описанию атрибутов основную сущность с данным атрибутом. Далее последовательно соединяем необходимые по смыслу сущности и их атрибуты.

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

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

Что делать, если не нашли в новой БД требуемых для витрины атрибутов:

1. Выясняем у коллег (аналитиков, руководителей, бизнес-заказчика), установлен ли алгоритм действия в данном случае, если установлен – действуем согласно алгоритму. Алгоритм может быть изложен в нормативной документации: регламенты, методички.
2. Если порядок действий не регламентирован (рекомендуемый порядок): а) Уведомляем своего руководителя об отсутствии данных в БД; б) Пишем уточняющих запрос по данному атрибуту в команду проектирования модели БД (действительно ли БД отсутствую данные); с) При получении ответа об отсутствии в БД необходимых данных – уведомляем бизнес-заказчика о проблеме, совместно прорабатываем пути решения.

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

Пятый и заключительный этап. Проверка корректности заполнения и согласование маппинга

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

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

Эти данные позволят провести миграцию витрины с сохранением ее логики и «полезности» для бизнес-заказчика. Необходимо уточнить регламент наименования атрибутов и сущностей у бизнес-заказчика.

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

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

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

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

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

Один из таких продуктов – Informatica PowerCenter. Это платформа интеграции данных, работающая на визуализацию данных без написания программного кода. Для формирования маппинга возможно использовать такие особенности и функции Informatica, как:

• Графическое представление потоков данных, анализ взаимосвязей и отслеживание данных;
• Реализация логики обработки данных в визуальной среде. Автоматизация запуска процессов также выполняется в визуальной среде;
• Наличие бизнес-глоссария (может и отсутствовать, но возможность его создания предусмотрена).

Что понравилось в Informatica, так это возможность через одну таблицу проанализировать – из каких таблиц-источников она собирается, а также в какие таблицы эти данные «уходят». Также удобно наличие бизнес-описания полей и таблиц (на практике такая информация не часто встречается).

Пример отображения информации в Informatica:

Стоит обратить внимание, что не каждая связь между таблицами может быть отражена в Informatica (заказчик мог ее и не занести).

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

Начнем с того, что ER-диаграмма – это схема «сущность-связь», разновидность блок-схемы, где показано – как разные «сущности» (сотрудники, договоры и т.п.) связаны между собой внутри системы. Как и в Informatica, ER-диаграмма – это наглядное представление связи таблиц через ключи. Ключи — один из способов категоризации атрибутов, применяются с целью максимально эффективно связать между собой разные таблицы в базе данных.

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

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

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

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

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

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

• Блог компании Neoflex
• Big Data

Источник: habr.com