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

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

Зачем писать

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

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

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

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

Когда писать

В госзакупках чаще всего сопровождение пишут:

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

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

Шаблон сопроводительного письма

Что писать

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

Составляет сопровод, как правило, тот сотрудник, который отправляет документацию. Для заверения достаточно подписи, но если организация использует печать, можно поставить и ее. Напомним, что теперь круглая печать не является обязательной (82-ФЗ от 06.04.2015).

Разрабатывая образец, как пишется сопроводительное письмо, можно придерживаться такой структуры:

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

Нумеруются сопровод по правилам делопроизводства, как вся корреспонденция. Впоследствии можно использовать эти данные в переписке, например, «Отвечая на ваше обращение исх. №… от …».

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

Далее подготовьте опись. Проще всего это сделать в виде таблицы. Укажите полное название каждого документа со всеми реквизитами (например, «Коммерческое предложение №11 от 01.12.2017 года»), число страниц, количество копий. В конце не помешает указать суммарное число страниц.

В предыдущей части были рассмотрены виды связей (один-к-одному, один-ко-многим, многие-ко-многим), а также один класс Book и его маппинг-класс BookMap. Во второй части обновим класс Book, создадим остальные классы и связи между ними, как это было изображено в предыдущей главе в Диаграмме баз данных, расположившейся над подзаголовком 1.3.1 Связи.

Код классов и маппингов (С комментариями)

Класс Книга

Public class Book { //Уникальный идентификатор public virtual int Id { get; set; } //Название public virtual string Name { get; set; } //Описание public virtual string Description { get; set; } //Оценка Мира фантастики public virtual int MfRaiting { get; set; } //Номера страниц public virtual int PageNumber { get; set; } //Ссылка на картинку public virtual string Image { get; set; } //Дата поступления книги (фильтр по новинкам!) public virtual DateTime IncomeDate { get; set; } //Жанр (Многие-ко-Многим) //Почему ISet а не IList? Только одна коллекция (IList) может выбираться с помощью JOIN выборки, если нужно более одной коллекции для выборки JOIN, то лучше их преобразовать в коллекцию ISet public virtual ISet Genres { get; set; } //Серия (Многие-к-одному) public virtual Series Series { get; set; } //Мнение и другое (Один-к-одному) private Mind _mind; public virtual Mind Mind { get { return _mind ?? (_mind = new Mind()); } set { _mind = value; } } //Автор (Многие-ко-многим) public virtual ISet Authors { get; set; } //Заранее инициализируем, чтобы исключение null не возникало. public Book() { //Неупорядочное множество (в одной таблице не может присутствовать две точь-в-точь одинаковые строки, в противном случае выбирает одну, а другую игнорирует) Genres = new HashSet(); Authors = new HashSet(); } } //Маппинг класса Book public class BookMap: ClassMap { public BookMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.Description); Map(x => x.MfRaiting); Map(x => x.PageNumber); Map(x => x.Image); Map(x => x.IncomeDate); //Отношение многие-ко-многим HasManyToMany(x => x.Genres) //Правила каскадирования All - Когда объект сохраняется, обновляется или удаляется, проверяются и //создаются/обновляются/добавляются все зависимые объекты.Cascade.SaveUpdate() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Genre! .Table("Book_Genre"); HasManyToMany(x => x.Authors) .Cascade.SaveUpdate() .Table("Book_Author"); //Отношение многие к одному References(x => x.Series); //Отношение один-к-одному. Главный класс. HasOne(x => x.Mind).Cascade.All().Constrained(); } }

Public class Author { public virtual int Id { get; set; } //Имя-Фамилия public virtual string Name { get; set; } //Биография public virtual string Biography { get; set; } //Книжки public virtual ISet Books { get; set; } //Инициализация Авторов public Author() { Books=new HashSet(); } } //Маппинг Автора public class AuthorMap: ClassMap { public AuthorMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.Biography); //Отношение многие-ко-многим HasManyToMany(x => x.Books) //Правила каскадирования All - Когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты.Cascade.All() //Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Book! .Table("Book_Author"); } }

Класс Жанр

Public class Genre { public virtual int Id { get; set; } //Название жанра public virtual string Name { get; set; } //Английское название жанра public virtual string EngName { get; set; } //Книжки public virtual ISet Books { get; set; } //Инициализация книг public Genre() { Books=new HashSet(); } } //Маппинг жанра public class GenreMap: ClassMap { public GenreMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.EngName); //Отношение многие-ко-многим HasManyToMany(x => x.Books) //Правила каскадирования All - Когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты.Cascade.All() //Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Book! .Table("Book_Genre"); } }

Класс Мнение:

Public class Mind { public virtual int Id { get; set; } //Мое мнение public virtual string MyMind { get; set; } //Мнение фантлаба public virtual string MindFantLab { get; set; } //Книга public virtual Book Book { get; set; } } //Маппинг Мind public class MindMap:ClassMap { public MindMap() { Id(x => x.Id); Map(x => x.MyMind); Map(x => x.MindFantLab); //Отношение один к одному HasOne(x => x.Book); } }

Класс Цикл(Серия):

Public class Series { public virtual int Id { get; set; } public virtual string Name { get; set; } //Я создал IList, а не ISet, потому что кроме Book, Series больше ни с чем не связана, хотя можно сделать и ISet public virtual IList Books { get; set; } //Инициализация книг. public Series() { Books = new List(); } } public class SeriesMap: ClassMap { public SeriesMap() { Id(x => x.Id); Map(x => x.Name); //Отношение один-ко-многим HasMany(x => x.Books) ////Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() } }

Небольшое объяснение
public virtual ISet Genres { get; set; }
public virtual ISet Authors { get; set; }

Почему ISet, а не, к примеру, привычный многим IList? Если использовать вместо ISet - IList, и попробовать запустить проект, то разницы особой мы не заметим (Таблицы и классы создадутся). Но когда мы к классу Book LeftJoin-им одновременно таблицу Genre и Authors, да и еще пытаемся вывести неповторяющиеся записи из таблицы Book (Distinct Book.Id) в представление (View), Nhibernate выдаст исключение и ошибку.
Cannot simultaneously fetch multiple bags.
В таких случаях используем ISet, тем более множества для этого и предназначены (игнорируют дублирующие записи).

Отношение многие-ко-многим.

В NHibernate есть понятие, «главной» таблицы. Хотя отношения «многие-ко-многим» между таблицами “Book” и “Автор” равнозначны (У автора может быть много книг, у книги может быть множество авторов), Nhibernate требует, чтобы программист указывал таблицу, которая сохраняется второй (имеет метод.inverse()), то есть вначале будет создана/обновлена/удалена запись в таблице Book, а только потом в таблице Author.
Cascade.All означает выполнение каскадных операций при save-update и delete. То есть когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты (Ps. Можно прописать вместо Cascade.All -> .Cascade.SaveUpdate().Cascade.Delete())
Метод.Table(«Book_Author»); создает «промежуточную» таблицу “Book_Author” в БД.

Отношение многие-к-одному, один-ко-многим.

Метод.Constrained() говорит NHibernate, что для записи из таблицы Book должна соответствовать запись из таблицы Mind (id таблицы Mind должен быть равен id таблицы Book)

Если сейчас запустить проект и посмотреть БД Bibilioteca, то появятся новые таблицы с уже сформированными связями.

Далее заполним созданные таблицы данными…
Для этого создадим тестовое приложение, которое будет сохранять данные в БД, обновлять и удалять их, изменив HomeController следующим образом (Ненужные участки кода комментируем):
public ActionResult Index() { using (ISession session = NHibernateHelper.OpenSession()) { using (ITransaction transaction = session.BeginTransaction()) { //Создать, добавить var createBook = new Book(); createBook.Name = "Metro2033"; createBook.Description = "Постапокалипсическая мистика"; createBook.Authors.Add(new Author { Name = "Глуховский" }); createBook.Genres.Add(new Genre { Name = "Постапокалипсическая мистика" }); createBook.Series = new Series { Name = "Метро" }; createBook.Mind = new Mind { MyMind = "Постапокалипсическая мистика" }; session.SaveOrUpdate(createBook); //Обновить (По идентификатору) //var series = session.Get(1); //var updateBook = session.Get(1); //updateBook.Name = "Metro2034"; //updateBook.Description = "Антиутопия"; //updateBook.Authors.ElementAt(0).Name = "Глуховский"; //updateBook.Genres.ElementAt(0).Name = "Антиутопия"; //updateBook.Series = series; //updateBook.Mind.MyMind = "11111"; //session.SaveOrUpdate(updateBook); //Удаление (По идентификатору) //var deleteBook = session.Get(1); //session.Delete(deleteBook); transaction.Commit(); } Genre genreAl = null; Author authorAl = null; Series seriesAl = null; Mind mindAl = null; var books = session.QueryOver() //Left Join с таблицей Genres .JoinAlias(p => p.Genres, () => .JoinAlias(p => p.Authors, () => authorAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Series, () => seriesAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Mind, () => mindAl, JoinType.LeftOuterJoin) //Убирает повторяющиеся id номера таблицы Book. .TransformUsing(Transformers.DistinctRootEntity).List(); return View(books); } }

Небольшое объяснение

1. var books = session.QueryOver() Select * From Book ;
2. .JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin) - подобно выполнению скрипта SQL:
   SELECT *FROM Book
   inner JOIN Book_Genre ON book.id = Book_Genre.Book_id
   LEFT JOIN Genre ON Book_Genre.Genre_id = Genre.id
3. .TransformUsing(Transformers.DistinctRootEntity) - Подобно выполнению скрипта SQL: SELECT distinct Book.Id... , (убирает дублирующие записи с одинаковыми id)

Виды объединений
.JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin)

1. LeftOuterJoin - выбирает все записи из левой таблицы (Book ), а затем присоединяет к ним записи правой таблицы (Genre ). Если не найдена соответствующая запись в правой таблицы, отображает её как Null
2. RightOuterJoin действует в противоположность LEFT JOIN - выбирает все записи из правой таблицы (Genre ), а затем присоединяет к ним записи левой таблицы (Book )
3. InnerJoin - выбирает только те записи из левой таблиц (Book ) у которой есть соответствующая запись из правой таблицы (Genre ), а затем присоединяет к ним записи из правой таблицы

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

Представление index

@model IEnumerable @{ Layout = null; }

@Html.ActionLink("Create New", "Create")

• При операциях Create и Update обновляются все данные, связанные с таблицей Book (уберите Cascade=«save-update» или cascade=«all» и связанные данные не будут сохранены)
• При удалении удаляются данные из таблиц Book, Mind, Book_Author, а остальные данные не удаляются, потому что у них Cascade=«save-update»

Маппинг для классов, у которых есть наследование.
А как маппить классы у которых есть наследование? Допустим, имеем такой пример:
//Класс Двумерных фигур public class TwoDShape { //Ширина public virtual int Width { get; set; } //Высота public virtual int Height { get; set; } } //Класс треугольник public class Triangle: TwoDShape { //Идентификационный номер public virtual int Id { get; set; } //Вид треугольника public virtual string Style { get; set; } }

В принципе, ничего сложного в этом маппинге нет, мы просто создадим один маппинг для производного класса, то есть таблицы Triangle.
//Маппинг треугольника public class TriangleMap: ClassMap { public TriangleMap() { Id(x => x.Id); Map(x => x.Style); Map(x => x.Height); Map(x => x.Width); } }
После запуска приложения, в БД Biblioteca появится следующая (пустая) таблица

Теги:

• asp.net mvc 4
• nhibernate
• sql server

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

Что означает понятие в общем?

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

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

Примеры мэппинга

Разберем, что это - мэппинг, на следующих примерах:

• Составление документа соответствий бухгалтерских счетов из различных их планов. Например, российского, МСФО, управленческого учета и проч.
• Перевод кодов базы данных одной системы в другую. К примеру, нам надо преобразовать обозначения 0 и 1 в "нет" и "да".
• Перевод долларов в евро - это мэппинг в каком-то роде.
• Изменение формата изображения.png в.jpg, фильма из.avi в.mp4, проводимое в графическом, видеоредакторе, в каком-то роде будет относиться к предмету нашего разговора.

Разработка компьютерных игр

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

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

• Создание карты территории и ее разбиение на зоны - города, горный массив, подземные туннели, леса и проч.
• Определение регионов, связанных с какой-то специфической деятельностью игрока, - поле боя, магазин дополнительных атрибутов, добыча ресурсов, укрепления, место отдыха, доска почета и проч.
• Проработка нестатических объектов. Ими могут быть ключи, двери, секретные кнопки и ходы, исчезающие тайные проходы и проч.
• Определение важных локаций организаций - это точка восстановления, клады, сокровища, тайники с секретным оружием и проч.
• Установление места начала и финиша перемещений для каждого из игроков.
• Оживление карты рядом деталей: добавление таких элементов, как текстуры, звуки, аудиосопровождение, зрительные эффекты, иллюзии, анимации и проч.
• Вставка необходимых триггеров (механизмов, которые проверяют наличие какого-либо объекта в создаваемом игровом пространстве) и скриптов (сценариев, кратких алгоритмов действий).
• Создание определенных скриптов передвижения мобов (нестатичных объектов, персонажей): зоны, где они могут перемещаться, их взаимодействие, диалог с игроком и проч.
• Иногда включает создание кат-сцен - красивой заставки, мини-фильма, своеобразного трейлера игры или уровня, группы "левелов", которую геймер может только просмотреть, но никак не повлиять на то, что в ней происходит.

Видео-мэппинг

Что такое видео-мэппинг (3D-мэппинг)? Это удивительная технология, которая позволяет проецировать изображения, специально созданные фильмы на масштабные неровные поверхности, например, на фасады строений.

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

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

Каким может быть видео-мэппинг?

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

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

Где применяется 3D-мэппинг?

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

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

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

Если вы хотите познакомиться с отзывами о технологии, то просто послушайте тех, кто хоть раз посещал московский "Круг света". С недавних пор каждый год осенью в столице проходит этот собирающий тысячи зрителей фестиваль. Дизайнеры из разных стран создают видеопроекции, которые показываются на фасаде Большого театра, главном павильоне ВДНХ, основном корпусе МГУ и пр.

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

Хранилище данных для финансового учреждения

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

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

1. Определение заинтересованных сторон в соответствии с бизнесом банка (розничные банковские услуги, корпоративный бизнес, кредитные карты, и т. п.).

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

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

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

3. Понимание концепции моделирования данных.

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

4. Коллективное выявление ландшафта исходных систем.

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

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

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

6. Мэппинг данных .

a) Мэппинг данных из источника (исходных систем в организации) в целевую структуру (модель данных хранилища).

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

b) Мэппинг данных для каждой функции с членами группы со стороны бизнеса и ИТ:

Этот мэппинг может потребоваться на двух уровнях:

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

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

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

7. Определение агрегирования .

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

8. Пропускание и именование элементов данных.

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

9. Декларация дальнейшего совершенствования процессов .

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

10. Выравнивание версий .

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

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

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

Сокращение многочисленных хранилищ данных до одного экземпляра

Компания Boeing прошла через этот процесс, начав с 12 хранилищами данных и 50 системами управления расходами, некоторые из которых имели десятки тысяч бизнес-правил. «Проблема заключалась в том, что наш IT-отдел предоставлял пользователям то, что им нужно, однако они не общались друг с другом», - говорит Билл Керли (Bill Curley) сотрудник финансового отдела Boeing. Это отсутствие интеграции являлось причиной несоответствия в отчетах.

У Boeing ушло несколько лет на консолидацию всей финансовой отчётности в единое целое. Работавшие над этой задачей члены проектной группы предпочли подход «сверху вниз» - они опросили «владельцев данных», какая информация им необходимо для выполнения работы, и внедрили стандартный словарь данных, имеющий минимум необходимых элементов. Кроме того, они разделили операционные и фактические бухгалтерские данные, необходимые для отчётов. «Нам больше не требовалось проводить оперативную информацию через нашу бухгалтерскую систему», - говорит Билл Керли.

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

Над этой задачей в течение нескольких последних лет работала компания Nike. Для этого архитектор данных компании Джеймс Ли (James Lee) устранил дублирующиеся данные, заполнил отсутствующие поля в таблицах и разобрался с серией отчётов, которые слишком долго формировались. «На пути к единой версии правды мы хотели достигнуть значительной гибкости, чтобы бизнес-подразделения могли генерировать свои отчёты без участия IT-отдела. Одной из целей была самодостаточность пользователей относительно работы с данными», - вспоминает он. Одна из наиболее часто используемых таблиц Nike содержала больше сотни столбцов. Это было чрезвычайно неэффективно с точки зрения операций ввода-вывода и использования вычислительных мощностей. Nike упростил эту сверхширокую таблицу и сократил свои модели данных до меньшего числа элементов. Этот процесс также улучшил качество данных, так как на пользователей возложили ответственности за отсутствующие, но необходимые элементы данных, и они стали более активными в их отслеживании.

Публикации

1. Аарти Няядиш (Aarti Nyayadish). «Идеальный проект хранилища данных: 10 шагов для установления верного темпа» (Ideal Banking Data Warehousing project: 10 steps for setting the right pace), 15 января 2013 г.
2. Дэвид Стром (David Strom). «Как справиться с избытком данных: как это сделали Boeing, Nike и другие» (Coping with Too Much Data: How Boeing, Nike and Others Did It), 23 октября 2012 г.

Проблема

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

Решение

Будем рассматривать данный кейс как продолжение предыдущего. Представим себе, что вы создали в Excel такой справочник:

Рис.2.1. Справочник: мэппинг статей БУ и УУ

Слева - статья затрат (БУ), справа статья управленческого учета (УУ). Важно при этом, чтобы в первом колонке статья затрат встречалась только один раз, иначе механизм мэппинга будет работать не корректно.

(Кстати, английское слово mapping переводится как отображение или соответствие, поэтому справочник в данном случае - это некое общее правило того, как статьи БУ находят свое отображение в статья УУ).

Рис.2.2. Плоская таблица: отчет о затратах (из "Оборотов счета 20")

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

Рис.2.3. Плоская таблица: отчет о затратах (из "Оборотов счета 20")

В нижней части формы указаны наименования страниц: "Главная" - это плоская таблица, в которой содержатся данные о затратах (рис.2.2), "спр" - это справочник (рис.2.1).

В верхней части формы указаны номер столбцов. Так, в данном случае, если данные в столбцах 1 справочника и 3 главной страницы совпадают, то данные из 2-го столбца справочника копируются в 7-й столбец главной страницы.

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

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

Рис.2.4. Отчет по затратам арматурного цеха

Сравнение мэппинга с ВПР()

Многие пользователи хорошо знакомы и пользуются функцией ВПР() в такого рода ситуациях. Однако функция ВПР() хорошо работает только на небольших объемах данны, в то время как данная форма отлично справляется с обработкой таблтц Excel, даже если у вас в справочнике, скажем, 5000 строк, а на гоавной странице - 300 000 строк. Попробуйте проверить, и вы убедитесь, что на таких объемах ВПР() дает сбои. Кроме того, функция ВПР() создает значительную нагрузку на Excel, вынуждая его проводить большие объесы калькуляций. Форма мэппинга позволяет избежать этого недостатка: она запускается один раз, действует несколько секунд (при больших объемах минут) и после этого никаких дополнительных нагрузок на файл Excel уже не создается.