В предыдущей части были рассмотрены виды связей (один-к-одному, один-ко-многим, многие-ко-многим), а также один класс 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
Public class Author {
public virtual int Id { get; set; }
//Имя-Фамилия
public virtual string Name { get; set; }
//Биография
public virtual string Biography { get; set; }
//Книжки
public virtual ISet
Класс Жанр
Public class Genre {
public virtual int Id { get; set; }
//Название жанра
public virtual string Name { get; set; }
//Английское название жанра
public virtual string EngName { get; set; }
//Книжки
public virtual ISet
Класс Мнение:
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 class Series {
public virtual int Id { get; set; }
public virtual string Name { get; set; } //Я создал IList, а не ISet, потому что кроме Book, Series больше ни с чем не связана, хотя можно сделать и ISet
public virtual IList
Небольшое объяснение
public virtual ISet
public virtual ISet
Почему ISet
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
Небольшое объяснение
Виды объединений
.JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin)
Изменим представление следующим образом:
Представление index
@model IEnumerable @Html.ActionLink("Create New", "Create")
@foreach (var item in Model) {
@Html.DisplayNameFor(model => model.Name)
@Html.DisplayNameFor(model => model.Mind)
@Html.DisplayNameFor(model => model.Series)
@Html.DisplayNameFor(model => model.Authors)
@Html.DisplayNameFor(model => model.Genres)
Операции
}
@Html.DisplayFor(modelItem => item.Name)
@Html.DisplayFor(modelItem => item.Mind.MyMind)
@{string strSeries = item.Series != null ? item.Series.Name: null;}
@Html.DisplayFor(modelItem => strSeries)
@foreach (var author in item.Authors) {
string strAuthor = author != null ? author.Name: null;
@Html.DisplayFor(modelItem => strAuthor)
}
@foreach (var genre in item.Genres) {
string strGenre = genre!= null ? genre.Name: null;
@Html.DisplayFor(modelItem => strGenre)
}
@Html.ActionLink("Edit", "Edit", new { id = item.Id }) |
@Html.ActionLink("Details", "Details", new { id = item.Id }) |
@Html.ActionLink("Delete", "Delete", new { id = item.Id })
Маппинг для классов, у которых есть наследование.
А как маппить классы у которых есть наследование? Допустим, имеем такой пример:
//Класс Двумерных фигур
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
После запуска приложения, в БД Biblioteca появится следующая (пустая) таблица
Теги:
Слышали ли вы о mapping? В русской транскрипции это мэппинг, маппинг. Понятие имеет несколько значений, которые не связаны друг с другом. Рассмотрим каждое из них в контексте области, где они актуальны.
Мэппинг, маппинг, маппирование, мапирование - это определение соответствия информации между двумя разными семантиками как одного объекта, так и нескольких. Иными словами, так называется преобразование данных из одной формы в другую.
Что такое мэппинг? В общем значении термин достаточно широк - это может быть как скрупулезное преобразование одной последовательности элементов в иную, так и обычная конвертация валюты, файлов. Таким образом, все то, что скрывается под разбираемым термином, лучше всего выразить англоязычным понятием data mapping.
Разберем, что это - мэппинг, на следующих примерах:
Мэппинг (от англ. map - "карта местности") также может выступать в значении дизайна уровней. Такое наименование имеет дисциплина в разработке видеоигр. Это прежде всего создание различной сложности уровней - проработка миссии игрока, дизайн локации, составление заданий и проч. Практически такая деятельность ведется в редакторе "левелов".
Технологии мэппинга здесь неоднородны - все зависит от бюджета разработчиков, характера, жанра создаваемой игры. Рассмотрим классический пример, чтобы иметь большее представление о понятии:
Что такое видео-мэппинг (3D-мэппинг)? Это удивительная технология, которая позволяет проецировать изображения, специально созданные фильмы на масштабные неровные поверхности, например, на фасады строений.
Уникальность этого в том, что оно позволяет "оживлять" дома, иные предметы интерьера тем, что придает им визуальную подвижность. А достигается все лишь установленными по определенному плану проекторами. "Магия" движущихся объемных изображений состоит в суперточном соответствии элементов, на которые отсвечивается картинка, и самой видеопроекции.
Хоть для многих из нас мэппинг - это достаточно новое направление, родился он еще в шестидесятых годах прошлого века. Его появлением мы обязаны Уолту Диснею и студии Disney. Тогда рабочим названием мэппинга были "затеняющие лампы", "пространство виртуальной реальности". Первым шоу считается аттракцион "Призрачное поместье" в Диснейленде. Для него были созданы искусственные отрубленные головы, на которые проецировалось изображение, "оживляющее" их.
В зависимости от объекта, на который отражается изображение, технология разделяется на несколько направлений:
Давайте посмотрим, где может оказаться актуальной такая технология:
Эффектнее всего такое шоу смотрится в темное время суток. Чтобы придать более поражающий эффект, организаторы сочетают его с подходящим объемным звуковым звучанием, живой музыкой, фейерверками.
Если вы хотите познакомиться с отзывами о технологии, то просто послушайте тех, кто хоть раз посещал московский "Круг света". С недавних пор каждый год осенью в столице проходит этот собирающий тысячи зрителей фестиваль. Дизайнеры из разных стран создают видеопроекции, которые показываются на фасаде Большого театра, главном павильоне ВДНХ, основном корпусе МГУ и пр.
Мэппинг - многозначное понятие. Это и сложная конвертация данных, и создание локаций в компьютерных играх, и шоу, основанное на проецировании изображений на масштабные и малые предметы.
Мэппинг — технология, с помощью которой возможна проекция видео или изображений на различного рода поверхности: здания, автомобили и так далее. Она позволяет устраивать развлекательные и завораживающие шоу-программы, как на улицах, так и в помещениях. Такие шоу всегда приковывают взгляд зрителей, оставляя огромное впечатление. При этом зрителю не требуется надевать очки или другие приспособления.
Технология также позволяет рекламировать что угодно на твёрдых поверхностях. Шоу, созданные с использованием данной технологии, отлично вписываются в крупные мероприятия, городские праздники, торжественные открытия магазинов, торговых центров, различных развлекательных объектов. При этом наибольшего эффекта можно добиться, проводя маппинг-шоу в ночное время суток. Особенно если оно сопровождается яркими фейерверками и живой музыкой.
Одна из разновидностей мэппинга — 3d мэппинг. Благодаря технологии 3d мэппинг можно делать здания, автомобили и различные элементы интерьера живыми, создавая у зрителя ощущение подвижности этих объектов. Основной закон технологии 3d мэппинга довольно прост: объекты проецирования изображений должны максимально точно соответствовать изображению проекции. Заказать такую услугу можно на сайте www.3dday.ru .
Как это работает?
При проецировании изображений на окружающие предметы обязательно учитываются геометрические параметры последнего. Технология 3d мэппинг предполагает использование специализированного оборудования, которое проектирует изображение таким образом, что зритель видит его объёмным с любого ракурса. В случае с видео мэппингом, визуальный эффект объёмного изображения заметен лишь с определённого положения. В этом и заключается разница между обычным мэппингом и технологией 3d мэппинг.
Для создания оптической иллюзии, в первую очередь, воспроизводят изображение проецируемого объекта на компьютере в виде 3d модели. Далее, эта модель корректируется согласно требованиям сценария шоу. Завершающим этапом является само проецирование созданной модели на реальный объект, по которому и была спроектирована модель.
Таким образом, несложная на первый взгляд технология 3d мэппинг создаёт мощнейшую оптическую иллюзию: зрителю кажется, будто меняется сам объект, когда как на самом деле изменяется лишь проекция. Впечатление от такой оптической иллюзии поистине ни с чем не сравнимо. И легко себе представить возможный эффект от рекламной кампании, проведенной с помощью мэппинга!
Компании, применяющие Excel для целей трансформации отчетности, получают ощутимую экономию при подготовке отчетности по МСФО. Если объемы транзакций позволяют обрабатывать учетные данные в электронных таблицах, целесообразно использовать Excel
12.01.2016Таблицы Excel помимо арифметической точности и наглядности процедур трансформации позволяют формировать данные для экономического анализа финансовой деятельности на основании результатов по МСФО, что превращает модель отчетности в инструмент управления.
На подготовительном этапе осуществляется анализ конкретных различий между МСФО, применимых к данной компании, и учетной практикой по РСБУ. Следует отметить, что нецелесообразно отталкиваться от правил российского учета, поскольку в данном случае сложно будет уйти от «приоритета формы над содержанием», - начинать следует с анализа компании в целом и ее деятельности с точки зрения МСФО.
Международные стандарты, имеющие отношение к каждому конкретному бизнесу, должны быть включены в состав учетной политики по МСФО. Например, торговое предприятие вряд ли будет использовать сложные финансовые инструменты или положения МСФО (IAS) 41 «Сельское хозяйство», а частная компания не должна раскрывать прибыль на акцию в соответствии с МСФО (IAS) 33 «Прибыль на акцию». Процедура формирования учетной политики должна быть нацелена не только на создание правил и меморандумов учета в соответствии с МСФО, но и на подготовку блока примечаний непосредственно отчетности по МСФО, содержащего основные аспекты учетной политики, обязательные к раскрытию в соответствии с МСФО (IAS) 1 «Представление финансовой отчетности».
Основываясь на полученной учетной политике по МСФО, следует выявить расхождения в оценках и принципах, применяемых в РСБУ, и сформировать список и правила расчета основных трансформационных корректировок, а также перечень дополнительной информации, необходимой для целей МСФО, но не учитываемой в соответствии с требованиями российского законодательства.
При первом применении международных стандартов в соответствии с МСФО (IFRS) 1 следует помнить об исключениях и упрощениях, разрешенных стандартом, и о том, что в дальнейшем данные послабления перестают действовать.
Процесс обновления учетной политики по МСФО, списка корректировок и перечня дополнительной информации должен быть постоянным, поскольку требования МСФО и российского законодательства постоянно дополняются.
Мэппинг - от английского mapping (соответствие, а также преобразование) - это процедура разноски данных в нескольких системах координат, в нашем случае конвертация остатков и оборотов, сформированных в соответствии с планом счетов РСБУ, в структуру плана счетов по МСФО (таблица 1).
Таблица 1. Пример мэппинга плана счетов
Несколько слов о составлении собственно плана счетов по МСФО.
Следует отметить, что чем больше аналитик содержит российский план счетов, тем проще осуществлять мэппинг и реклассификационные корректировки, необходимые в связи с различными принципами агрегации данных в РСБУ и МСФО. Поэтому по возможности следует максимально приблизить план счетов РСБУ и его аналитику к нуждам МСФО, чтобы повысить эффективность процесса трансформации и снизить издержки.
Сбор информации, необходимой для заполнения трансформационной модели. На данном этапе собираются данные по остаткам балансовых счетов и оборотам доходно-расходных счетов за отчетный период, заполняется исходный баланс и отчет о прибылях и убытках.
Одновременно с этим процессом анализируются существенные операции, судебные споры, крупные новые контракты, дополнительные раскрытия. Должен быть разработан регламентированный перечень дополнительной информации, а также назначены ответственные за подготовку соответствующих данных и установлены сроки исполнения.
Перечень, представленный в таблице 2, может быть как сокращен, если у компании отсутствуют те или иные операции, так и существенно расширен. Как правило, в деятельности компании изменения, влекущие дополнительные корректировки по МСФО, возникают редко. Поэтому наиболее тщательный анализ делается во время первичного ознакомления с бизнесом, а уже затем отслеживаются существенные изменения. Таким образом, в большинстве случаев компании должны составлять порядка десяти-двадцати трансформационных корректировок, которые могут быть регламентированы соответствующими методическими указаниями и закреплены в документе «Порядок учета трансформационных корректировок».
Таблица 2. Примерный перечень дополнительной информации
Все корректировки следует оформлять в виде рабочего документа наподобие бухгалтерской справки. Рабочий документ должен содержать методологические основы и фактические предпосылки, на основании которых были сделаны те или иные корректировки, и непосредственно сами расчеты. Также необходимо установить контрольные процедуры, направленные на проверку правильности расчетов, сверку данных рабочих документов и трансформационных моделей, а также корректности проводок.
Этап формирования входящих корректировок . Входящие корректировки формируются при первом применении МСФО, а также при сделках по приобретению новых компаний, которые должны оцениваться по справедливой стоимости.
Для начала осуществляется перегруппировка статей баланса и отчета о прибылях и убытках. Это так называемые реклассификационные корректировки. К основным реклассификационным корректировкам относятся разворачивание или сворачивание дебиторской и кредиторской задолженности и авансов, рекласс расходов будущих периодов, разделение краткосрочных и долгосрочных активов и обязательств, перенос депозитов со сроком погашения менее 90 дней в денежные средства, а также более детальная разноска доходов и расходов на соответствующие счета, если подобная работа не была сделана на этапе мэппинга (таблица 3).
Таблица 3. Пример реклассификационной таблицы
Следующий блок корректировок - это исправления, влияющие на величину статей баланса, а также доходов и расходов. Следует не смешивать их с реклассификационными корректировками, поскольку только расчетные корректировки влияют на величину отложенных налогов по МСФО.
На практике наиболее существенные суммы корректировок связаны с оценкой активов по справедливой стоимости - основных средств (особенно в случаях, когда компания владеет старыми фондами) и нематериальных активов. Своими силами рассчитать подобные корректировки невозможно, поскольку для этого необходимы данные отчета об экспертизе, проведенной квалифицированным оценщиком. Например, без специальных знаний и опыта невозможно определить стоимость клиентской базы, которая при покупке компании должна признаваться в качестве нематериального актива по МСФО. Только после получения данных оценки о справедливой сумме первоначальной стоимости, степени износа, оставшегося полезного срока использования формируются реестры основных средств и нематериальных активов по МСФО. Учет основных средств и нематериальных активов может осуществляться как в отдельной программе, так и в электронных таблицах, когда в Excel ведется реестр основных средств, отражаются поступления, модернизации, выбытия объектов, рассчитывается амортизация по стоимости, признанной в соответствии с МСФО.
Наиболее простой способ расчета корректировок заключается в сопоставлении данных РСБУ и МСФО и определении расхождения между ними. Данные суммы и формируют поправку (таблица 4).
Таблица 4. Расчет корректировки по дооценке основных средств по справедливой стоимости
Помимо отражения переоценки, по основным средствам и нематериальным активам бывает необходимо пересчитывать сумму капитализированных процентов, поскольку РСБУ и МСФО содержат разные подходы при определении суммы капитализации.
Положения стандарта МСФО (IAS) 36 «Обесценение активов» также в большей степени направлены на тестирование основных средств и нематериальных активов, чья стоимость должна корректироваться при наличии признаков обесценения.
Если компания использует инструменты финансовой аренды в своей деятельности (в том аспекте, как ее интерпретируют МСФО), поправки также могут затрагивать сумму основных средств и расходов по амортизации, в корреспонденции с обязательствами по финансовой аренде и задолженности по процентам за пользование кредитными средствами.
Особое внимание стоит уделять корректировкам, связанным с дисконтированием (как, например, в случае с долгосрочной финансовой арендой, когда на основе дисконтирования оценивается и стоимость основных средств, и задолженность по договорам финансовой аренды). В МСФО требуется дисконтировать любые долгосрочные активы и обязательства:
Среди наиболее часто встречающихся корректировок можно также отметить:
После формирования всех расчетных поправок определяется сумма корректировки отложенного налога на прибыль.
Конечно же, перечислены далеко не все возможные корректировки, поскольку задача состоит в том, чтобы продемонстрировать, каким образом формируется пул входящих корректировок и как корректировки должны переноситься из года в год (таблица 5).
Таблица 5. Формирование списка входящих корректировок
Далее с учетом входящих корректировок осуществляется подготовка баланса, отчета о прибылях и убытках, отчета об изменении капитала, отчета о движении денежных средств в формате МСФО, а также выполняется подготовка пояснений к отчетности.
Первичные корректировки используются для переноса в отчетность следующих периодов в качестве входящих поправок. Существует два способа переноса:
Выбор метода переноса влияет только на технику расчета текущих корректировок для следующих отчетных периодов, конечный результат будет одинаков, однако поменять модель расчета корректировок уже будет нельзя, поэтому следует заранее определить наиболее удобный метод и придерживаться его.
Этап формирования корректировок для последующих отчетных периодов . Типовые корректировки в следующих отчетных периодах необходимо составлять с учетом входящих корректировок. Механизм формирования данных МСФО заключается в следующем - в таблицах Excel заполняются постранично:
Затем с помощью формул «СУММЕСЛИ» подтягиваются данные на сводный лист (см. таблицу 6).
Таблица 6. Формирование данных МСФО в трансформационной модели
Данные МСФО (столбец 8) получаются путем суммирования исходных данных РСБУ, реклассифицирующих, входящих и текущих корректировок. На следующем этапе также с помощью формулы «СУММЕСЛИ» готовые показатели МСФО агрегируются на страницах отчетов (баланса, отчета о прибылях и убытках) по кодам строк форм отчетности в соответствии с присвоенным кодом формы отчетности (таблица 7). Аналогичным образом заполняются табличные формы примечаний, прописываются контрольные и сверочные формулы между трансформационной таблицей, формами отчетности и примечаниями, сопоставляется изменение нераспределенной прибыли за период с начальным и конечным сальдо по показателю (возможны расхождения на сумму начисленных дивидендов).
Таблица 7. Пример использования функции Excel «СУММЕСЛИ»
Как мы видим, Excel позволяет достаточно просто и наглядно формировать данные МСФО путем трансформации. На практике применяются и другие подходы к заполнению трансформационных таблиц, например, наподобие классической шахматки. Однако если корректировок много, получаются громоздкие файлы и возрастает риск технических ошибок, более того, становится сложно анализировать накопленные за несколько периодов поправки. Какая бы ни применялась модель трансформации, существуют универсальные рекомендации по работе с Excel: должно быть организовано хранение данных на надежных и защищенных от постороннего доступа серверах, автоматическое создание резервных копий основных рабочих файлов и автосохранение в процессе работы, регулярное архивирование как первичных данных, так и финальных моделей, отслеживание внесения изменений в файлы и ведение сводного файла-статуса (контрольного листа), содержащего информацию о необходимых этапах выполнения трансформации и степени выполнения установленных процедур.
В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».
При этом основной акцент в статье будет сделан, прежде всего, на технологическую составляющую процесса миграции. Организационная составляющая также затронута, но в меньшей степени.
Под миграцией данных принято понимать конечную последовательность работ, проект, направленный на разовое массовое перемещение данных из систем-источников (исторические системы) в систему-приёмник. При этом эксплуатация этих данных в системах-источниках прекращается.
Следует отличать миграцию данных от интеграции данных. Интеграция, в отличие от миграции - это постоянная часть архитектуры IT, и ответственна за потоки данных между различными системами и хранилищами данных - и является процессом, а не деятельностью по осуществлению проекта.
Схема миграции в общем случае выглядит следующим образом:
Рис. 1
Исторические системы - базы данных компании Заказчика, которые планируется полностью или частично заменить при внедрении новой системы.
Система-приёмник - целевая система, произвольная конфигурация «1С:Предприятие 8».
Исходные данные - данные, выгруженные из исторических систем в произвольный формат xls -файлов. В данном случае формат xls представляется, как один из самых удобных, поскольку возможность выгрузки в xls -файл присутствует во многих учетных системах «предыдущих поколений».
Как современную альтернативу в качестве транспорта возможно рассматривать формат xml -файлов.
Также существуют варианты использования промежуточной базы данных.
Трансформация, конвертация - процесс преобразования исходных данных в данные для загрузки. Трансформация данных происходит в соответствии с шаблонами для загрузки. Результатом трансформации являются данные для загрузки.
Данные для загрузки - данные, предназначенные для загрузки в систему-приёмник. В данной статье, так же как и исходные данные, рассматривается xls -формат.
Шаблоны данных для загрузки - описание таблиц данных для загрузки в целевую систему.
Рассмотрим поэтапно процесс подготовки и проведения миграции.
К организационным этапам миграции можно отнести следующие пункты:
· Определение стратегии миграции. На данном этапе Исполнитель и Заказчик договариваются о технологии проведения миграционных работ;
· Определение состава рабочей группы по миграции. В рабочую группу должны входить специалисты и Исполнителя и Заказчика, знакомые в достаточной степени с работой исторических систем (со стороны Заказчика) и целевой системы (со стороны Исполнителя);
· Предварительный план миграции. План миграции по ходу проекта будет неоднократно корректироваться;
· Периоды дат выгрузки данных из исторических систем, объемы данных. Периоды среза данных для миграций, даты тестовых и итоговой миграций. Данную информацию можно отнести к плану миграции;
· Состав данных, подлежащих миграции. Справочные данные, классификаторы, транзакционные данные, остатки, обороты и пр.;
· Вопросы проверки качества, корректности и целостности данных в процессе миграции и по итогам;
· Вопросы отката к предыдущему состоянию в случае сбоев.
Остановимся подробнее на технологических этапах миграции.
Рис. 2
Шаблон загрузки данных содержит технические описания таблиц данных для загрузки, алгоритмы и правила загрузки для текущего шаблона.
Каждый шаблон в общем случае предназначен для одной или нескольких связанных таблиц в целевой системе-приёмнике.
В шаблоне указывается:
· Описание всех полей xls -файла данных для загрузки, включая:
o Имя поля
o Признак обязательности заполнения поля
o Пример заполнения поля
o Примечание
· Описание правил загрузки таблицы целевой системы на основании данных для загрузки (очередность в случае нескольких связанных таблиц, алгоритмы поиска по ключевым полям и т.п.)
· Описание заполнения непосредственно полей таблиц целевой системы в случае, если предусматривается что-либо отличное от переноса данных «один в один» из файла данных для загрузки. Актуально для ссылочных полей, например.
В процессе работ по данному этапу Исполнитель также должен подготовить загрузчик файлов данных для загрузки. В случае работы с файлами xls данная задача не представляет особой сложности.
Данный этап может начинаться вместе с предыдущим этапом «1. Подготовка шаблонов загрузки данных».
В рамках данного этапа специалисты Заказчика определяют из каких систем и какие данные могут быть выгружены. Также следует определить какие данные возможно могут понадобиться.
Как правило, в больших проектах миграции выявление полного исчерпывающего списка источников данных может занимать достаточно продолжительное время и происходит по мере работ на последующих этапах.
Нередки ситуации, когда для обеспечения в дальнейшем целостности информации некоторые данные приходится переносить с печатных источников (оцифровывать) или даже заносить в таблицы со слов ключевых сотрудников Заказчика.
Тем не менее, на данном этапе нужно постараться выявить как можно больше необходимых данных.
Процесс выгрузки данных из исторических систем может занять достаточное количество времени, особенно, если систем много, они разные и за них ответственны разные подразделения Заказчика. Необходимо учитывать данный момент при тестовых и итоговой миграциях.
Наиболее удобным вариантом представляется выгрузка в xls файлы. Многие старые IT -системы поддерживают такой вариант.
Также могут быть варианты выгрузки в csv формат, dbf , xml форматы и прочие.
Стоит отметить, что по тем или иным причинам (вопросы безопасности, например) Заказчик не всегда может предоставить выгрузки данных в полном объеме на этом этапе! Только структура данных и несколько тестовых позиций. Таким образом, может сложиться такая ситуация, что при тестовых и итоговой загрузках будут обнаруживаться некачественные данные в исходных таблицах, что будет приводить к незапланированным ошибкам.
Для минимизации данной проблемы следует оговорить заранее объемы тестовых выгрузок из исторических систем.
Мэппинг (data mapping ) - в общем случае процесс сопоставления данных исторических систем и системы-приемника. То есть, исходных данных и данных для загрузки.
Этап мэппинга - наиболее трудоёмкий этап и может занимать более 50% всех работ по задаче миграции.
На данном этапе в полной мере задействуется вся рабочая группа проекта по миграции.
В процессе мэппинга данных необходимо выделить подэтапы мэппинга таблиц и мэппинга полей.
· Мэппинг таблиц, или мэппинг шаблонов - сопоставление таблиц исходных данных и шаблонов данных для загрузки. Соответствие может быть как 1:1, так и N :N . В результате данной работы составляется и поддерживается реестр мэппинга таблиц. Данный подэтап необходим для следующего подэтапа мэппинга полей и для отслеживания общего состояния дел по мэппингу.
Группа шаблонов 1С |
Наименование шаблона 1С |
Наименование файла- источника |
Правила формирования файла-источника |
Ответственный |
Статус |
Примечание |
НСИ |
Шаблон_ Номенклатура |
Номенк латура.xls |
В системе N установить отбор |
Иванов И.И. |
в работе |
· Мэппинг полей - сопоставление полей таблиц в рамках уже определенного мэппинга таблиц. Результатом данной работы является реестр мэппинга полей.
№пп |
Кл. поле |
Обязательный |
Имя поля шаблона 1С «Шаблон_Номенклатура» |
Описание |
Имя поля «Номенклатура.xls» |
Алгоритм заполнения |
||||||||
Код |
Код элемента справочника |
Код |
||||||||||||
Наименование |
Наименование |
|||||||||||||
Да |
Это группа |
Содержит одно из значений: |
Если длина кода=11 символов и последние 4 символа <> "0000", то это элемент - "0", иначе группа - "1". |
|||||||||||
Полное наименование |
Наименование элемента справочника |
Наименование |
Если ЭтоГруппа =1 , То "", ИначеЕсли ЭтоГруппа=0, то Наименование. |
|||||||||||
В рамках данного этапа также следует провести возможные работы по нормализации данных.
В отличие от предыдущих этапов, данный этап - технический и предполагает работу разработчика Исполнителя.
На основании согласованных реестров мэппинга полей специалисты Исполнителя разрабатывают правила трансформации данных.
Для оперативной работы в процессе подготовительных миграционных этапов и дальше, в ходе тестовых и итоговых миграций важно, чтобы существовала удобная среда разработки правил (скриптов) трансформации данных и среда конвертации исходных данных в данные для загрузки.
При этом требования к данной среде включают в себя:
· Удобство и быстрота разработки правил трансформации;
· Скорость конвертации данных. Файлы на входе и на выходе могут быть и в сотни тысяч строк!
· Возможность работать с несколькими входными файлами одновременно;
· Возможность сохранения правил трансформации в отдельные файлы.
Для своих проектов миграции мы разработали специализированное АРМ разработчика, взяв за основу стандартную обработку «Консоль запросов» 1С.
Обработка «Консоль запросов» была доработана для возможности делать прямые запросы к файлам xls .
Приведем пример объединения двух исходных xls -файлов Сотрудники. xls
Код сотрудника |
Фамилия |
Имя |
Отчество |
Дата рождения |
2423 |
Иванов |
Иван |
Иванович |
17.11.1992 |
1523 |
Петров |
Василий |
Александрович |
04.02.1991 |
4363 |
Сидоров |
Кирилл |
Николаевич |
01.05.1995 |
Денисов |
Денис |
Денисович |
01.01.1990 |
и Операции. xls со страницами:
Списания
Код сотрудника |
Дата |
Сумма |
2423 |
01.02.2014 |
|
1523 |
02.02.2014 |
|
4363 |
03.02.2014 |
|
04.02.2014 |
100000 |
|
2423 |
05.02.2014 |
|
1523 |
06.02.2014 |
|
4363 |
07.02.2014 |
2356 |
08.02.2014 |
140000 |
|
2423 |
09.02.2014 |
|
1523 |
10.02.2014 |
|
4363 |
11.02.2014 |
23523 |
12.02.2014 |
80000 |
и Поступления :
Код сотрудника |
Дата |
Сумма |
||
01.05.2004 |
||||
02.05.2004 |
||||
03.05.2004 |
||||
04.05.2004 |
||||
2423Дата рождения |
Сумма поступление |
Сумма списание |
||
Иванов Иван Иванович |
2423 |
17.11.1992 |
1341234 |
1010 |
Петров Василий Александрович |
1523 |
04.02.1991 |
245245 |
|
Денисов Денис Денисович |
01.01.1990 |
380000 |
320000 |
|
Сидоров Кирилл Николаевич |
4363 |
01.05.1995 |
613382 |
26336 |
ИТОГО: |
2579861 |
347842 |
Отметим, что пример является искусственным, специально подобранным для демонстрации всех возможных стадий трансформации источников данных.
Технологическая последовательность операций трансформации здесь выглядит следующим образом:
С помощью языка запросов Access SQL (дающего существенные дополнительные возможности, по сравнению с языком запросов 1С) создается первоначальный запрос, извлекающий данные из файла xls в среду 1С. При этом уже на данном этапе возможны различные проверки и нормализации данных.
Технология доступа к данным ADO обеспечивает высокую скорость работы.
Рис. 3
2.Запрос на языке 1С - основной запрос, реализующий алгоритм мэппинга полей. А также: обогащение загружаемых данных данными из базы 1С, перегруппирование, объединение с результатами запросов к другим исходным xls -файлам и пр.
3.Постобработка результата запроса 1С при необходимости. Реализуется с помощью скрипта на языке 1С.
Для примера здесь реализуется добавление строки «ИТОГО» по колонкам сумм.
4.Запись итогового набора данных в xls -файл.
В общем случае на выходе мы получаем итоговые файлы для загрузки в целевую базу данных 1С.
Также данный инструмент позволяет сохранять правила конвертации данных в отдельный xml файл:
Кроме того, реализована возможность работать в пакетном режиме , что особенно актуально при большом количестве разнородных мигрирующих данных.
В ходе предыдущих этапов подготовительная часть работы в целом заканчивается - выявлены все источники данных, сделана выгрузка исходных данных из источников, подготовлены шаблоны загрузки в целевую базу, подготовлен мэппинг данных и, наконец, разработаны скрипты трансформации данных.
Следует отметить, что перед итоговой миграцией обязательно следует провести несколько тестовых. В ходе тестовых миграций Исполнитель совместно с Заказчиков выявляют:
· ошибки конвертации, ошибки загрузки данных
· проводят предварительную оценку качества загружаемых в целевую систему данных
· по итогам тестовых миграций составляют/актуализируют план итоговой миграции
Проверка качества загруженных данных должна производиться как после тестовых миграций, так и по окончанию итоговой миграции. В ходе выверки могут проверяться следующие показатели:
· Совпадения итоговых сумм по остаткам, по документам;
· Количественные совпадения, например количество ОС;
· Корректность заполнения отдельных выборочных сущностей;
Обращаем внимание, что те или иные проверки мигрирующих данных, вопросы нормализации данных необходимо решать на протяжении всех миграционных процессов. Необходимо всегда задаваться вопросом, что нужно сделать на текущем этапе, чтобы избежать ошибок на последующих этапах.
Например:
· Проверка на дубли по ключевым полям. Можно и нужно проводить еще на исходных данных;
· Приведение типов полей;
· Ссылочная целостность;
· Математические нестыковки. Например, проверка на незаполненные численные поля, на которые запланировано деление при трансформации;
· В целом, проверки обязательной заполненности полей;
· Замена некорректных символов. Например, английские символы в кириллических полях («о», «а», «е» и т.п.) Особенно актуально это для ключевых полей!
· Проверка значений строковых полей на соответствие типов системы-приемника (Ограничения по длине)
После завершения итоговой миграции согласно заранее определенной стратегии миграции и плану миграции принимается решение о дальнейшей эксплуатации исторических систем.
Часто эксплуатация завершается сразу после финальных сверок данных и фиксирования успешности проведенной миграции - пользователи новой системы уже не ведут учет параллельно в двух системах, а полностью переходят в новую систему. При этом доступ к старой системе сохраняется в режиме чтения.
В некоторых случаях может происходить параллельная работа двух систем на время опытной эксплуатации (ОЭ) и даже более этого периода. Вопрос параллельной работы пользователей в двух системах тесно связан с вопросом возможности отката к старой системе, в случае если миграция (или же, в целом, работа новой системы!) будет признана неудовлетворительной.
В заключении хотелось бы отметить, что когда речь идёт о миграции больших транзакционных систем, к которым относятся и многие конфигурации «1С:Предприятия», переход на новую систему может быть весьма трудоёмким.
Поэтому следует помнить, что любой подобный проект требует тщательной подготовки и должен сопровождаться индивидуальным планом. Однако независимо от типа мигрируемых систем, объемов баз данных и пр. общая схема миграции выглядит практически идентично.