Что такое мэппинг? Трансформация российской отчетности с помощью Excel.

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

разработка и реализация бизнес-стратегии;
осуществление планирования и контроля;
эффективное использование ресурсов;
повышение эффективности деятельности;
сохранение материальных и нематериальных активов;
корпоративное и внутрифирменное управление бизнес-процессами

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

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

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

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

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

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

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

Возможны следующие варианты организации взаимосвязи:

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

Первый вариант организации взаимосвязи информационных учетных систем с формами отчетности (посредством таблиц описания взаимосвязей) называется «мэппинг».

Мэппинг (в широком понимании) – это преобразование данных из одной формы в другую. Для бухгалтерского учета мэппинг – это составление таблицы соответствий бухгалтерских счетов из различных планов счетов, например российского плана счетов и плана счетов GAAP (МСФО) (или плана счетов управленческого учета).

Пример 1. Смешанный вариант организации взаимосвязи.

Большинство компаний составляют отчетность, например по МСФО, путем трансформации. Метод основан на подходе, в соответствии с которым информация, сформированная по российским стандартам, анализируется и корректируется для приведения ее в соответствие с МФСО.

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

1-й этап. Структурная трансформация баланса и отчета о прибылях и убытках. В результате делаются перегруппировка и агрегирование отдельных статей финансовой отчетности в целях подготовки базы данных для выполнения последующих корректирующих проводок. При этом таблица мэппинга содержит показатели финансовой отчетности по РСБУ и их отражение в промежуточной отчетности по МСФО.

2-й этап. Выполнение корректирующих проводок, направленных на устранение качественных различий между российской отчетностью и отчетностью по МСФО. Делается специалистом по трансформации вручную.

3-й этап. Составление отчетности по МФСО на основе трансформированных баланса, отчета о прибылях и убытках и прочих форм. Таблица мэппинга включает показатели промежуточной отчетности по МСФО и описание корректировок, сделанных специалистом по трансформации.

4 –й этап. Подготовка описательной части отчета.

Таблица 1. Иллюстрация взаимоувязки российского плана счетов бухгалтерского учета с планом счетов GAAP (извлечение)

Инвестиционный департамент (облагаемый)

Investm. Depart (Deductible)

Департамент оценки

Valuat dept. (deductible)

Исследовательский департамент (облагаемый)

Research dept. (deductible)

НДС по реализации НДС

НДС - услуги

Cons services VAT

Итого выручка

Gross Sales/revenues

Себестоимость реализации

Investm. Depart (Deductible)

Прочие налоги начисленные (НсП)

Other tax collection

Торговая наценка (скидка, накидка)

The trade margin (discount, addition)

Скидка поставщиков на возмещение транспортных расходов

The discount of the suppliers on redress of transportation costs

Реализация и выбытие основных средств

Disposal of fixed assets

Реализация прочих активов

Disposal of other assetses

Основное производство

The basic production

Вспомогательное производство

Supplementary productions

Общепроизводственные расходы

General production expenditures

Департамент маркетинга (облагаемый)

Market Depart (Deductible)

Департамент маркетинга (необлагаемый)

Market Depart (nonDeduclible)

	Продажи – основная деятельность		Sales/revenues – main activity
	Себестоимость реализации
	Валовая прибыль		Net sales
	Общие, коммерческие и административные расходы		Selling general and administrative expenses

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

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

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

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

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

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

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

Безусловно, на практике увязка показателей (мэппинг ) управленческого, налогового и бухгалтерского (финансового) учета вызывает массу проблем.
Рассмотрим некоторые из них.

1. Нехватка аналитики в рабочем плане счетов (далее РПС) фирмы.

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

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

финансовой (бухгалтерской);
налоговой;
управленческой.

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

Финансовая (бухгалтерская) составляющая. Использование РПС должно обеспечить возможность формирования всех (без исключения) результатных учетно-аналитических показателей внешней финансовой отчетности и пояснительной записки в разрезе бухгалтерских счетов Главной книги на отчетную дату. Блок бухгалтерских счетов РПС, задействованных для формирования внешней бухгалтерской отчетности, – это финансовые счета. В свою очередь, финансовые счета подразделяются на аналитические и синтетические. Субсчета финансового учета РПС являются промежуточными между аналитическими и синтетическими. Причем финансовые аналитические и синтетические счета, а также субсчета могут представлять собой неотъемлемую часть управленческой составляющей РПС. Так, например, данные, отраженные на отдельных субсчетах финансового счета 90 «Продажи», имеют важное значение для принятия управленческих решений.

При формировании группы финансовых счетов РПС необходимо выполнить следующие требования:

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

Налоговая составляющая. Применение РПС в системе бухгалтерского учета обеспечивает возможность исчислять налоговую базу и величину прибыли для целей налогообложения в соответствии с требованиями гл. 25 НК РФ. Реализация налоговой составляющей системного подхода к РПС предполагает:

организацию аналитического финансового и налогового учета расходов и доходов с целью выявления их влияния на величину налогооблагаемой базы для исчисления налога на прибыль коммерческой организации путем детализации финансовых счетов (01 – 99) РПС;
разработку перечня налоговых счетов (например, 101–199). Их внедрение даст возможность вести учет отклонений учетных данных объектов финансового и налогового учета с целью создания на базе финансового учета и финансовой отчетности налогового учета и налоговой отчетности;
разработку правил, позволяющих откорректировать влияние налоговой составляющей на единую интегрированную бухгалтерскую отчетность с целью исключения дублирования отчетных (результатных) учетно-аналитических показателей.

Управленческая составляющая . В РПС для получения результатных учетно-аналитических показателей управленческой внутренней отчетности и ведения управленческого учета выделяется блок управленческих счетов (например, 201–299). На этих управленческих счетах осуществляется двойная запись регулировок к финансовым счетам 01–99 исходя из требований, предъявляемых пользователями к внутренней управленческой отчетности. В дальнейшем данные на управленческих счетах 201–299 при использовании определенных правил дополняют (корректируют) данные на финансовых счетах 01–99. Результатом таких действий являются показатели внутренней управленческой отчетности.

Реализация управленческого аспекта в системном подходе к формированию РПС предполагает разработку:

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

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

Таблица 2. Мэппинг операций российского бухгалтерского (финансового) учета для формирования строк формы корпоративной отчетности «Баланс» (извлечение)

Дебетовый оборот

ОС в организации

Группы ОС: <все>

Вложено во внеоборотные
активы

Не изменять

Подразделения: <все>

Без изменений

Код Проекта: <все>

Не разворачивать

В групповом контроле участвует с плюсом

Основные Средства: Прочие основные фонды

Объекты Строительства (р): Вид Поступления ОС (Поступление от сторонних организаций)

Дебетовый оборот

ОС без регистрации

Группы ОС: <все>

Не изменять

Подразделения: <все>

Без изменений

Код Проекта: <все>

Не разворачивать

В групповом контроле участвует с плюсом

Основные Средства: Прочие основные фонды

Объекты Строительства (р): Вид Поступления ОС (Поступление от сторонних организаций)

Дебетовый оборот

МЦ в организации

Вложено во внеоборотные активы

Не изменять

Без изменений

Не разворачивать

В групповом контроле участвует с плюсом

Основные Средства(р): Вид Поступления ОС (Поступление от сторонних организаций)

Дебетовый оборот

МЦ, перед. во временное владение

Контрагенты: <все>

Вложено во внеоборотные
активы

Не изменять

Договоры: <все>

Без изменений

Код Проекта: <все>

Не разворачивать

В груповом контроле участвует с плюсом

Основные Средства: Прочие основные фонды

Объекты Строительства (р): Вид ПоступленияОС (Поступление от сторонних организаций)

Дебетовый оборот

МЦ, перед. во временное пользование

Контрагенты: <все>

Вложено во внеоборотные
активы

Не изменять

Договоры: <все>

Без изменений

Код Проекта: <все>

Не разворачивать

В групповом контроле участвует с плюсом

	Строка Баланса	Счет БУ	Отбор по субконто 1	Корр. счет БУ	Отбор по субконто 1	Формула отбора
		Отбор по субконто 2		Отбор по субконто 2	Инвертировать знак
		Отбор по субконто 3		Отбор по субконто 3	Учет НДС
		Отбор по субконто 4		Отбор по субконто 4	Разворачивать по
		Отбор по субконто 5		Отбор по субконто 5	Участие в групповом счете

BL00102 Введено в эксплуатацию (+)

Введено в эксплуатацию (+)

Введено в эксплуатацию (+)

Введено в эксплуатацию (+)

Введено в эксплуатацию (+)

Введено в эксплуатацию (+)

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

единый интегрированный план счетов финансового, налогового и управленческого учета;
интегрированный план счетов финансового и налогового учета, автономный план счетов управленческого учета;
интегрированный план счетов финансового и управленческого учета; автономный план счетов налогового учета;
интегрированный план счетов налогового и управленческого учета; автономный план счетов финансового учета;
автономные планы счетов финансового, налогового, управленческого учета.

2. Проблемы построения справочников и классификаторов, основными из которых являются:

дублирование информации в справочниках;
некорректная кодировка срок справочников.

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

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

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

– Несовместимость частей автоматизированной системы учета.
Например, снабжающее подразделение ведет регистры и справочники МТЦ в программе Cache, а бухгалтерские (финансовые) и управленские регистры, справочники ведутся в SAP R3, там же формируется отчетность компании. Форматы представления данных в этих программах различны, поэтому конвертация данных между ними затруднена, а в некоторых случаях напрямую невозможна.

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

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

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

Если справочник сильно детализирован, то его тяжело наполнять информацией и использовать в работе. Например, справочник «Движение денежных средств» может содержать более тысячи различных назначений платежа. Подготовка отчета о движении денежных средств по основным платежам для генерального директора потребует много времени, поскольку придется провести необходимую группировку (укрупнение показателей или выборку необходимой из массива избыточной информации). Кроме того, при вводе информации пользователь может не знать, куда необходимо отнести тот или иной платеж. Это неизбежно приведет к неверному выбору позиций из справочника или отнесению платежа к «прочим». Можно порекомендовать детально описать, какие объекты учета могут быть отражены по каждой строке справочника.

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

– Следует избегать использования похожих кодировок в разных справочниках.
Например, если при анализе продаж отдел маркетинга выделяет группы покупателей не по регионам, а по городам и областям, то группы для анализа не должны совпадать с кодами федеральных регионов. В противном случае это приведет к ошибкам при вводе информации. Так, для Москвы установлен код «77», а на предприятии под этим кодом числится Белгородская область. В результате сотрудник может отнести определенный вид продаж не к области, а к Москве, и информация будет искажена. В данном случае рекомендуется создавать коды разной длины, например для кодировки маркетинговых групп использовать три цифры (код «770» для клиентов Белгородской области);

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

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

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

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

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

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

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

Эта технология в чем-то аналогична прокси серверу, однако она гораздо проще и гораздо менее гибкая.

Схема примерно такая же, как и при использовании прокси (можно сказать, что port mapping похож на proxy - но это будет то же. что сказать "дедушка похож на внука" - вообще-то это как раз proxy похож на port mapping):

Ваш компьютер >>> компьютер с port mapping >>> удаленный сервер.

Для чего нужен port mapping?

Если в организации используется корпоративный прокси, то настроив на нем port mapping на внешний почтовый сервер (mail.ru), Вы сможете использовать любую почтовую программу изнутри корпоративной сети - и Вам не потребуется устанавливать/настраивать никаких дополнительных программ!
Точно таким же образом как почтовую программу, Вы можете настроить практически любую другую программу! Лишь бы она поддерживала TCP/IP.

Разумеется это только основные способы применения port mapping. Существует еще масса видов деятельности, где он также будет весьма и весьма полезен.

Преимущества port mapping

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

Недостатки port mapping

Эта система не отличается гибкостью. В отличие от прокси, у которого через один прокси можно подключиться на множество сайтов, через один port mapping можно подключиться только к одному серверу.
Для каждого нового port mapping нужно изменять настройки на сервере, где реализована эта функция - с клиентского компьютера это недоступно.
В интернете нет бесплатных port mapper-ов (ввиду их крайней ограниченности - один port mapping дает доступ только на один сервер), поэтому если Вы хотите быть действительно анонимным на своем компьютере, Вам нужно где-то иметь сервер, на котором будет установлена программа для маппинга портов - и вот уже адрес этого сервера и будет "светиться" в логах веб-сайтов.

Как работать с port mapping

Учтите, схема работы с port mapping примерно та же, что и при работе с proxy, только еще проще. Port mapping - это алиас (дополнительное имя) для компьютера, на который он настроен.

Предположим, что сделан port mapping:

192.168.1.255:1234 => www.mail.ru:80 (80-й порт - это порт web серверов)

Тогда для того, чтобы открыть сайт mail.ru, Вы можете использовать 2 способа - откройте в окошке браузера сайт:

http://www.mail.ru
http://192.168.1.255:1234/
(в данном случае обязательно пишите http:// )

Хотелось бы заметить: если Вам нужно использовать port mapping, то Вы должны пользоваться только вторым адресом . То есть если Вы не можете подключиться к mail.ru, то Вы должны использовать только внутренний адрес (http://192.168.1.255:1234/).

Port mapping на локальном компьютере

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

local port - локальный порт на Вашем компьютере, к которому Вы должны будете подключаться для использования port mapping. Это число может быть любым (от 1 до 65535), желательно больше 1000;
remote host - тот компьютер (хост), на который указывает port mapping. Например, это может быть почтовый сервер pop.mail.ru ;
remote port - порт компьютера, к которому будет происходить подключение через port mapping. Для получения почты (POP3) это обычно порт 110 , для отправки почты (SMTP) - порт 25, для web серверов (www...) - это обычно порт 80.

Так вот, в этом случае Вам нужно (настроив port mapping) подключаться не к mail.ru (и им подобным), а указать в качестве сервера Ваш же компьютер:

127.0.0.1:localport

где localport - это номер порта, заданный при настройке port mapping. Например это может быть порт 1234.

То есть если Вы сделали port mapping на web сайт, то Вам нужно писать: http://127.0.0.1:1234/

Если же Вы настраиваете почту - то в качестве почтового сервера укажите 127.0.0.1 - как для получения, так и для отправки почты. И не забудьте найти настройки номеров портов (POP3 и SMTP) в Вашем почтовом клиенте и изменить их в соответствии с Вашими же настройками в port mapping!

Замеппленые классы должны декларировать столбец первичного ключа в таблице базы данных. Большинство классов также должны описывать собственные свойства в стиле JavaBeans, включая уникальный идентификатор сущности. Элемент в mapping-файле определят отображение этого уникального поля на столбец таблицы, выступающий в роли основного ключа (primary key).

(5)

(1)	name (необязательный): Наименование свойства идентификатора.
(2)	type (необязательный): Имя определяющее Hibernate-тип свойства.
(3)	column (необязательно - по умолчанию имя свойства): Название колонки основного ключа.
(4)	unsaved-value (необязательно - по умолчанию null): Значени свойства идентификатора, которое обзначает, что экземпляр новый (в терминах персистентного хранилища). Отличает данный экземпляр от транзитных экземпляров, которые были загружены или сохранены в предыдущей версии.
(5)	access (необязательный - по умолчанию property): Эту стратегию Hibernate будет использовать для доступа к данному свойству объекта.

Если атрибут name не указан, предполагается, что класс не имеет свойства идентификатора.

Атрибут unsaved-value важен! Если свойство идентификатор вашего класса по умолчанию не null, вы должны установить атрибут "unsaved-value" в соответствующее значение.

Существует альтернативное объявление для доступа к унаследованным (legacy) данным c композитными ключами. Мы настойчиво не рекомендуем использовать композитные ключи в других случаях.

5.1.4.1. generator

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

uid_table next_hi_value_column

Все генераторы реализуют интерфейс net.sf.hibernate.id.IdentifierGenerator. Это очень простой интерфейс; многие приложения могут использовать свою специальную реализацию генератора. Несмотря на это, Hibernate включает в себя множество встроенных генераторов. Ниже идут краткие наименования (ярлыки) для встроенных генераторов:

Increment

генерирует идентификаторы типа long, short или int, уникальные только когда другие процессы не добавляют данные в ту же таблицу. Не использовать в кластере.

identity

Поддерживает identity колонки в in DB2, MySQL, MS SQL Server, Sybase и HypersonicSQL. Тип возвращаемого идентификатора long, short или int.

sequence

Использует последовательность (sequence) в DB2, PostgreSQL, Oracle, SAP DB, McKoi или generator в Interbase. Тип возвращаемого идентификатора long, short или int.

hilo

Использует hi/lo алгоритм для эффективной генерации идентификаторов которые имеют тип long, short или int, требуют наименования таблицы и столбца (по умолчанию hibernate_unique_key и next_hi соответсвенно), как источник значений hi. Алгоритм hi/lo генерирует идентификаторы которые кникальный только для отдельный баз данных. Не используйте этот генератор для соединений через JTA или пользовательских соединений.

seqhilo

использует алгоритм hi/lo для генерации идентификаторов типа long, short или int, с использованием последовательности (sequence) базы данных.

uuid.hex

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

uuid.string

использует тот же UUID алгоритм, однако строка при использовании этого генератора состоит из 16 (каких-то) ANSII символов. Не использовать с PostgreSQL.

native

выбирает identity, sequence или hilo, в зависимости от возможностей используемой базы данных.

assigned

предоставляет приложению возможность самостоятельно задать идентификатор объекта перед вызовом метода save().

foreign

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

5.1.4.2. Алгоритм Hi/Lo

Генераторы hilo и seqhilo предоставляют две альтернативные реализации алгортма hi/lo, наиболее предпочтительного подхода для генерации идентификаторов. Первая реализация требует "специальной" таблицы в базе данных, для хранения следующего "hi" значения. Вторая реализация использует последовательность (Oracle-style), в базах данных, которые их поддерживают.

hi_value next_value 100 hi_value 100

К сожалению вы не можете использовать hilo в случае поставки своего соединения (Connection) в Hibernate, так же невозможно его использование в конфигурации, когда Hiberante использует источник данных сервера приложений, управляемый JTA. Hiberante должен иметь возможность получать "hi" значение в новой тразакции. Стандартным подходом в EJB, является использование session stateless bean для реализации алгоритма hi/lo.

5.1.4.3. Алгоритм UUID

Не пробуйте использовать uuid.string в PostgreSQL.

5.1.4.4. Последовательности и identity колонки

Вы можете использовать генератор ключей identity для баз данных с поддержкой indentity столбцов (DB2, MySQL, Sybase, MS SQL). Для баз данных поддерживающих последовательности можно использовать sequence стиль для генерации ключей. Обе эти стратегии требуют двух SQL запросов для вставки нового объекта в базу данных.

uid_sequence

Для разработки кроссплатформеннох приложений используйте стратегию native. Она будет использвать identity, sequence и hilo стратегии в зависимости от возможностей той базы данных с которой в данный момент времени работает Hibernate.

5.1.4.5. Задаваемые идентификаторы

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

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

5.1.5. composite-id

......

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

Ваш персистентный класс должен переопределять методы equals() и hashCode() для реализации эквивалентности композитных идентификаторов. Он так же должен реализовывать интерфейс Serializable.

К сожалению, возможность задавать составные идентификаторы подразумевает то, что персистентный объект и есть идентификатор. Нет возможности для удобной обработки, чем посредством самого объекта. Вы должны создать сущность персистентного класса самостоятельно и установить его идентифицирующее свойство перед тем как выполнить загрузку load() персистентного состояния ассоциированного с данным составным идентификатором. Мы опишем более подходящий способ, где составные идентификаторы реализованы отдельным классом в разделе Раздел 7.4, «Компоненты как составные идентификаторы» . Атрибуты, которые описываются ниже, применимы только для альтернативного метода:

name (необязательно): свойство типа копонента, которое содержит составной идентификатор (см. следующий раздел).

class (опционально, по умолчанию тип свойства определяет через рефлексию): компонент данного класса используется как составной идентификатор (см. следующий раздел).

unsaved-value (опционально, по умолчанию none): если установлен в any, то это указывает на то, что транзитные сущности рассматриваются как новые.

5.1.6. discriminator

Элемент необходим для полиморфной персистентности, использующей стратегию отображения table-per-class-hierarchy. Данный элемент объявляет колонку-дискриминатор, по которой определяется соответствие записи в таблице конкретному классу в иерархии. Дискриминатор может иметь один из следующих типов: string, character, integer, byte, short, boolean, yes_no, true_false.

Соответствующие значения колонки дискриминатора для каждого класса задаются в атрибуте discriminator-value для элементов и .

Атрибут force полезен только в случае, если таблица содержит записи с дополнительными значениями дискриминатора, которые не отображаются в персистентном классе. Обычно данный атрибут не используется.

5.1.7. version (необязательно)

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

(1)	column (необязательно, по умолчанию берется имя свойства): имя колонки, которая хранит номера версий.
(2)	name: Имя свойства персистентного класса.
(3)	type (необязательно, по умолчанию integer): тип свойства версии.
(4)
(5)	unsaved-value (необязательно, по умолчанию undefined): Значение свойства версии, которое указывает на то, что сущность еще не сохранена (unsaved). Не путайте несохраненные сущности от транзитных, которые были сохранены или загружены в предыдущей сессии. (undefined указывает на то, что будет использовано значение идентификатора.)

Номера версий могут быть типа long, integer, short, timestamp либо calendar.

5.1.8. timestamp (необязательно)

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

(1)	column (необязательно, по умолчанию используется имя свойства): имя колонки, которая содержит временную метку.
(2)	name: Имя в стиле JavaBeans типа Date или Timestamp свойства персистентного класса.
(3)	access (необязательно, по умолчанию property): стратегия, которую должен использовать Hibernate для доступа к значению свойства.
(4)	unsaved-value (необязательно, - по умолчанию null): Значение свойства времени, которое указывает на то, что сущность еще не сохранена (unsaved). Не путайте несохраненные сущности от транзитных, которые были сохранены или загружены в предыдущей сессии. (undefined указывает на то, что будет использовано значение идентификатора.)

Примечание: элемент эквивалентен элементу .

5.1.9. property

Элемент Объявляет персистентное, в стиле JavaBeans, свойство класса.

(1)	name: Имя свойства, начинается с буквы в нижнем регистре.
(2)	column (необязательно, по умолчанию подставляется название свойства): имя соответствующей колонки в таблице базы данных.
(3)	type (необязательно): название Hibernate-типа.
(4)	update, insert (необязательно, по умолчанию true) : указывает на то, что соответствующая колонка должна включаться в SQL-выражения UPDATE и/или INSERT. Установка обоих свойств в false позволяет задавать значение этого свойства либо из другого свойства, которое отображено в той же колонке/колонках, либо посредством триггера, либо другим приложением.
(5)	formula (необязательно): SQL-выражение, которое вычисляет значение свойства. Вычисляемые поля не должны отображаться в колонку таблиц базы данных.
(6)	access (необязательно, по умолчанию property): стратегия, которую Hibernate должен использовать для доступа к значению свойства.

значение свойства type может быть одним из следующих:

Имя базового типа Hibernate (например, integer, string, character, date, timestamp, float, binary, serializable, object, blob).

Имя Java-класса (например, int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob).

Имя производного от PersistentEnum класса (например, eg.Color).

Имя сериализуемого Java-класса.

Имя пользовательского класса (например, com.illflow.type.MyCustomType).

Если вы не указываете значение свойства type, Hibernate будет использовать рефлексию для указанного свойства для подбора соответствующего Hibernate типа. Hibernate попытается определить имя класса возвращаемого свойства методом get() используя правила 2, 3, 4 в этом порядке. Тем не менее, этого не всегда бывает достаточно. В некоторых случаях вам все же необходимо указать атрибут type. (Например для различия между Hibernate.DATE и Hibernate.TIMESTAMP, либо для указания пользовательского типа.)

Атрибут access позволяет управлять задавать Hibernate метод доступа к полю во время исполнения. По умолчанию Hibernate вызывает методы get/set для доступа к полю. Если вы задаете access="field", то Hibernate будет обходить методы get/set и обращаться к полю напрямую, используя рефлексию. Вы можете указать вашу собственную стратегию для доступа указав класс, который реализует интерфейс net.sf.hibernate.property.PropertyAccessor.

5.1.10. many-to-one

Обычная связь с другим персистентным классов объявляется используя элемент many-to-one. В реляционных терминах это ассоциация многих к одному. В действительности это просто ссылка на объект.

(1)	name: Имя свойства.
(2)	column (необязательно): Имя колонки.
(3)	class (необязательно - по умолчанию тип поля определяется через рефлексию): Имя ассоциированного класса.
(4)	cascade (необязательно): Определяет, какая операция будет выполняться каскадом от родительского объекта к ассоциированному.
(5)
(6)	update, insert (необязательно - по умолчанию true) определяет то, что отображаемые колонки будут включены в SQL-запросы UPDATE и/или INSERT. Установка обоих свойств в false позволяет задавать значение этого свойства либо из другого свойства, которое отображено в той же колонке/колонках, либо посредством триггера, либо другим приложением.
(7)	property-ref: (необязательно) Имя ключевого свойства ассоциированного класса. По этому свойству будет происходить связывание (join). Если не указано, то используется первичный ключ ассоциированного класса.
(8)	access (необязательно - по умолчанию property): Стратегия, которую использует Hibernate для доступа к значению данного поля.

Атрибут cascade может принимать следующие значения: all, save-update, delete, none. Установка значения отличного от none повлечет определенные операции над ассоциированным (дочерним) объектом. См ниже "Жизненный цикл объектов".

Атрибут outer-join может принимать три следующих значения:

auto (по умолчанию) извлекает ассоциированные объекты используя outer join если ассоциированный класс не имеет прокси.

true Всегда извлекать ассоциированные объекты используя outer join.

false Никогда не извлекать ассоциированные объекты используя outer join.

Типичное объявление ассоциации many-to-one выглядит так

Атрибут property-ref использоваться только для связи c унаследованными данными, когда внешний ключ ссылается на уникальное значение ассоциированной таблицы отличной от первичного ключа. Это опасное реляционное решение. Например, возможно, что класс Product имеет уникальный последовательный номер, который не является первичным ключем. (Атрибут unique конролирует герерацию DDL Hibernate"ом. Генерация производится при помощи утилиты SchemaExport.)

Отображение для OrderItem может использовать:

В действительности, так делать крайне не рекомендуется.

5.1.11. one-to-one

Ассоциация "один к одному" с другим персистентным классом можно объявить, используя элемент one-to-one.

(1)	name: Имя свойства.
(2)	class (необязательно - по умолчанию определяется рефлексией исходя из типа поля): Имя ассоциированного класса.
(3)	cascade (необязательно) определяет какая операция будет выполняться каскадом от родительского объекта к ассоциированному.
(4)	constrained (необязательно) определяет то, что внешний ключ, ссылающийся на таблицу ассоциированного класса, ограничен первичным ключом этой таблицы. Эта опция влияет на порядок, в котором выполняются каскадные операции save() и delete() (а так же используется утилитой экспортирующей схему - schema export tool).
(5)	outer-join (необязательно - по умолчанию auto): Задействует извлечение ассоциированных объектов, используя объединения outer-join если опция hibernate.use_outer_join конфигурационного файла включена.
(6)	property-ref: (необязательно) Имя свойства ассоциированного класса, которое входит в первичный ключ данного класса. Если не указано, то используется первичный ключ ассоциированного класса.
(7)	access (необязательно, по умолчанию property): Стратегия, которую должен использовать Hibernate для доступа к данному полю.

Существует два вида ассоциаций "один к одному":

связь по первичному ключу

связь по уникальному внешнему ключу

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

Для ассоциации по первичному ключу добавьте следующее отображение для классов Employee и Person соответственно.

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

employee ...

Сохраняемому экземпляру класса Person присваивается тоже значение первичного ключа, которое присвоено экземпляру класса Employee на который ссылается свойство employee класса Person.

Как альтернативный вариант описания связи "один к одному" от Employee к Person, через уникальный внешний ключ можно использовать следующую запись:

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

5.1.12. component, dynamic-component

Элемент отображает поля вложенного объекта на колонки таблицы родительского класса. Компоненты могут в свою очередь определять свои собственные свойства, компоненты или коллекции. Смотрите "Компоненты" ниже.

(5) ........

(1)	name: Наименование свойства (ссылающегося на компонентный объект).
(2)	class (необязательно - по умолчанию тип компонента определяется используя рефлексию): Наименование класса компонента.
(3)	insert: Если установлен в true, то отображаемые поля компонента участвуют в SQL-запросах INSERT.
(4)	update: Если установлен в true, то отображаемые поля компонента участвуют в SQL-запросах UPDATE.
(5)	access (необязательно - по умолчанию property): Стратегия, которую должен использовать Hibernate при доступе к этому компоненту через родительский объект.

Вложенные тэги Отображают поля компонента в колонки таблицы.

Элемент допускает вложенный элемент Который отображает свойство компонента как обратную ссылку на родительский объект.

Элемент позволяет использовать Map как компонент, в котором имена полей соответствуют ключам Map"а.

5.1.13. subclass

И наконец, полиморфная персистентность требует объявления каждого подкласса базового класса. Для (рекомендованной) стратегии отображения table-per-class-hierarchy используется элемент .

.....

Каждый подкласс должен объявлять свои собственные персистентные поля и подклассы. Допускается наследование свойств и от базового класса. Каждый подкласс в иерархии должен определять уникальное значение discriminator-value. Если это значение не указано, то в качестве дискриминатора используется полное имя класса.

5.1.14. joined-subclass

В качестве альтернативы, подкласс, объекты которого хранятся в отдельной таблице (стратегия отображения table-per-subclass), объявляется используя элемент .

.....

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

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

Все типы в Hibernate, за исключением коллекций, поддерживают семантику null-указателей.

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

5.2.2. Базовые типы-значения

Базовые типы могут быть грубо разделены следующим образом

integer, long, short, float, double, character, byte, boolean, yes_no, true_false

Мапинги примитивных Java-типов либо классов оберток на соответсвующие (зависимые от поставщика) SQL-типы колонок таблиц. boolean, yes_no и true_false являются альтернативными обозначениями для Java-типов boolean или java.lang.Boolean.

string

Отображение типа java.lang.String в VARCHAR (либо Oracle VARCHAR2).

date, time, timestamp

Отображение типа java.util.Date и его подклассов в в SQL-типы DATE, TIME и TIMESTAMP (либо эквивалентные).

calendar, calendar_date

Отображение типа java.util.Calendar в SQL-типы TIMESTAMP и DATE (либо эквивалентные).

big_decimal

Отображение типа java.math.BigDecimal в NUMERIC (или Oracle NUMBER).

locale, timezone, currency

Отображение типа java.util.Locale, java.util.TimeZone и java.util.Currency в VARCHAR (или Oracle VARCHAR2). Экземпляры Locale и Currency отображаются в их ISO коды. Экземпляры TimeZone отображаются в их идентификаторы (ID).

class

Отображение типа java.lang.Class в VARCHAR (или Oracle VARCHAR2). Class отображается как его полное имя.

binary

Отображает массивы байтов в соответствующий бинарный SQL-тип.

text

Отображает длинные строки Java в SQL CLOB либо TEXT.

serializable

Отображает сериализуемые Java-типы в соответствующие бинарные SQL-типы. Вы так же можете обозначить Hibernate-типом serializable имя сериализуемого Java-класса либо интерфейса, который не является базовым типом и не реализует интерфейс PersistentEnum.

clob, blob

Отображение типа JDBC классов java.sql.Clob и java.sql.Blob. Эти типы могут быть неудобными для некоторых приложений, так как объекты типов blob и clob не могут использоваться вне транзакций. (К тому же, драйвера поддерживают эти типы не полностью и неодинаково.)

Уникальные идентификаторы сущностей и коллекций могут быть любого базового типа за исключением binary, blob и clob. (Составные идентификаторы так же допускаются, смотри ниже.)

Базовые типы-значения описываются константами объявленными в net.sf.hibernate.Hibernate. Например, Hibernate.STRING представляет тип string.

5.2.3. Персистентные перечисляемые типы (enum)

Перечисляемый тип является базовой идиомой Java когда класс имеет константное (небольшое) количество неизменяемых экземляров (прим. переводчика в Java 5 это введено на уровне языка, в более ранних версиях для этого применялся специальных паттерн). Вы можете создавать персистентные перечисляемые типы реализуя интерфейс net.sf.hibernate.PersistentEnum, и определяя операции toInt() и fromInt():

Package eg; import net.sf.hibernate.PersistentEnum; public class Color implements PersistentEnum { private final int code; private Color(int code) { this.code = code; } public static final Color TABBY = new Color(0); public static final Color GINGER = new Color(1); public static final Color BLACK = new Color(2); public int toInt() { return code; } public static Color fromInt(int code) { switch (code) { case 0: return TABBY; case 1: return GINGER; case 2: return BLACK; default: throw new RuntimeException("Unknown color code"); } } }

Имя Hibernate-типа - это просто имя перечисляемого класса, в данном случае eg.Color.

5.2.4. Пользовательские типы-значения

Для разработчиков относительно просто создать свои типы-значения. Например, вы можете захотеть сохранять свойства типа java.lang.BigInteger в колонки типа VARCHAR. Hibernate не предоставляет встроенного типа для этого. Но определение пользовательских типов не огранивается отображением свойств (либо элементов коллекций) в единичный столбец таблицы. Таким образом, например, вы можете иметь свойство getName()/setName() типа java.lang.String которое хранится в колонках FIRST_NAME, INITIAL, SURNAME.

Для реализации пользовательского типа, реализуйте один из интерфесов net.sf.hibernate.UserType либо net.sf.hibernate.CompositeUserType и объявите свойство, используя полное имя класса вашей реализации типа. Просмотрите net.sf.hibernate.test.DoubleStringType для уточнения доступных возможностей.

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

Хотя богатство встроенных Hibernate-типов и поддержка компонентов подразумевает то, что нужда в использовании пользовательских типов возникает достаточно редко, все же считается хорошей практикой использование последних в качестве (не сущностных) классов для типов, часто используемых в вашем приложении. Например, класс MonetoryAmount хороший кандидат для CompositeUserType, хотя он может отображаться как компонент. Главная мотивация это абстракция. С пользователскими типами, ваш документ маппинга будет более усточивым к возможным изменениям в будущем в случае если вы измените представление денежного типа.

5.2.5. Отображение Any типа

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

Атрибут meta-type позволяет приложению задать пользовательский тип, который отображает значения колонок базы данных в персистентные классы, свойства-идентификаторы которых имеют тип, определеный в id-type. Если мета-тип (meta-type) возвращает сущности java.lang.Class, то больше ничего не требуется. В остальных случаях, когда это базовый тип, такой как string или character вы должны определить соответствие значений классам.

..... .....

(1)	name: Имя свойства.
(2)	id-type: Тип идентификатора.
(3)	meta-type (необязательно - по умолчанию class): тип, который отображает java.lang.Class в одну колонку базы данных либо, в качестве альтернативы, тип, который разрешен для отображения дискриминатора.
(4)	cascade (необязательно - по умолчанию none): тип каскадной операции.
(5)	access (необязательно - по умолчанию property): Стратегия, которую должен использовать Hibernate для доступа к значению свойства.

Старое свойство object, которое занимает отдельное место в Hibernate 1.2, все еще поддерживается, но объявлено полу-устаревшим.

5.3. SQL-идентификаторы в кавычках

Вы можете принудить Hibernate заключать идентификаторы в кавычки в SQL выражениях. Hibernate будет следовать правилам заключения в кавычки согласно установленного диалекта SQL (обычно двойные кавычки, но скобки для SQL Server и обратные кавычки для MySQL).

...

5.4. Отдельные файлы отображения

Можно объявлять отображения subclass и joined-subclass в отдельных документах, прямо внутри элемента hibernate-mapping. Это позволяет расширять иерархию классов добавлением нового файла отображения. При таком подходе вы должны указать атрибут extends в отображении подкласса, содержащий имя предварительно замапленного суперкласса. Использование данной возможности делает важным порядок перечисления документов отображений.

Часть 3. Отображение данных из таблицы (Операция LIST)

В предыдущей части были рассмотрены виды связей (один-к-одному, один-ко-многим, многие-ко-многим), а также один класс 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); } }

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

var books = session.QueryOver() Select * From Book ;
.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
.TransformUsing(Transformers.DistinctRootEntity) - Подобно выполнению скрипта SQL: SELECT distinct Book.Id... , (убирает дублирующие записи с одинаковыми id)

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

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

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

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

@model IEnumerable @{ Layout = null; } Index

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

@foreach (var item in Model) { @{string strSeries = item.Series != null ? item.Series.Name: null;} }

@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)	@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 })

Проверив поочередно все операции, мы заметим, что:

При операциях 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 появится следующая (пустая) таблица

Теги: Добавить метки

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

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

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

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 упростил эту сверхширокую таблицу и сократил свои модели данных до меньшего числа элементов. Этот процесс также улучшил качество данных, так как на пользователей возложили ответственности за отсутствующие, но необходимые элементы данных, и они стали более активными в их отслеживании.

Публикации

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