код обд нси что это

Об итогах заседания Координационного комитета по информатизации

В центральном офисе ОАО «Газпром» состоялось очередное заседание Координационного комитета по информатизации под руководством заместителя Председателя Правления — начальника Финансово-экономического департамента Андрея Круглова.

В работе заседания приняли участие члены Координационного комитета по информатизации, руководители Управляющих комитетов проектов по информатизации, руководители и специалисты структурных подразделений ОАО «Газпром» и профильных дочерних обществ ООО «Информгаз» и ЗАО «Информгазинвест».

На заседании были рассмотрены результаты работы по проектам создания:

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

По итогам заседания управляющим комитетам проектов поручено обеспечить ввод систем в постоянную эксплуатацию в установленные Планом реализации Стратегии информатизации ОАО «Газпром» сроки.

Справка

Стратегия информатизации ОАО «Газпром» утверждена Постановлением Правления ОАО «Газпром» 17 января 2008 года. Стратегия определяет ключевые направления развития в ОАО «Газпром» информационных технологий, обеспечивающих достижение стратегических целей компании.

В рамках первого этапа реализации Стратегии работы ведутся согласно плану, утвержденному на расширенном заседании Координационного комитета по информатизации, состоявшемся 20 июня 2008 года под руководством Председателя Правления ОАО «Газпром» Алексея Миллера.

Целью построения Отраслевого банка данных документарной и фактографической нормативно-справочной информации (ОБД НСИ) в ОАО «Газпром» является создание основы для формирования единого информационного пространства за счет применения единой методологии, регламентов и инструментов ведения НСИ. В основу реализации ОБД НСИ легло использование специализированных программных продуктов SAP MDM, SAP XI, SAP Enterprise Portal. Основным результатом создания ОБД НСИ станет обеспечение целостной и непротиворечивой НСИ для формирования корпоративной отчетности Группы Газпром.

Целями проекта построения внутрикорпоративного интернет-портала ОАО«Газпром» являются: создание единой среды для доступа к информационно — управляющим системам, реализуемым на базе различных программных платформ, и информационно-справочным системам ОАО «Газпром»; обеспечение доступа пользователей к информационным ресурсам вне зависимости от их местонахождения в соответствии с регламентами разграничения доступа; создание единой технологической платформы обеспечения коллективной работы различных групп пользователей. В основу реализации интернет-портала легло использование специализированного программного продукта SAP Enterprise Portal. Основным результатом создания портала станет технологическая интеграция компонентов целевой системной архитектуры и интеграция доступа к их ресурсам пользователей ОАО «Газпром» и его дочерних обществ.

Целью проекта создания Информационной системы «Транспорт, подземное хранение и использование газа, объекты энергетики» ОАО «Газпром» является повышение эффективности информационного обеспечения Департамента по транспортировке, подземному хранению и использованию газа ОАО «Газпром» и снижение трудоемкости процесса сбора, обработки и хранения данных о деятельности дочерних обществ и организаций ОАО «Газпром» по виду деятельности «транспортировка газа и газового конденсата». В основу реализации системы легло использование программных продуктов SAP BI и SAP Enterprise Portal. Результатом реализации проекта должно стать решение следующих задач: автоматизация процесса сбора, обработки и хранения данных; уточнение методик заполнения шаблонов отчетных форм и регламентов предоставления данных.

Источник

Анатомия системы НСИ

Данная статья основана на реальных событиях,
и все проблемы в ней не вымышленные. (С)

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

Вот и в моём случае оказалась та же картина — система стоит на продуктиве более десяти лет, строилась по тому же принципу, если что нужно, рисуем и включаем в оборот. Таким образом были созданы несколько таблиц для хранения разного рода оборудования. Но вот пришёл час Х, когда стало необходимо добавить ещё пару таблиц для нового оборудования и при этом все (включая старые) должны входить в определённую группу. Это значит, что ссылки на разные таблицы должны быть включены в кросс-таблицу между группой и всеми пятью видами оборудования, то есть для каждого своё поля с констреинтом на соответствующую таблицу. А если ещё одно добавится, менять структуру. И обработку нужно делать в зависимости от того, какие поля заполнены. Вот и возникает первая проблема, как разные таблицы обобщить, что бы с ними одинаково можно было работать и не менять структуру, если добавляется ещё одна. Замечательная мысль, создаём отдельную табличку, которая призвана хранить абстрактное понятие оборудование с указанием типа, а тогда остальные таблички ссылаются по внешнему ключу на своего родителя. На этой радостной волне мы заливаем в созданную табличку записи из одной и пытаемся тоже сделать для другой. Но что-то пошло не так, сработало ограничение первичного ключа, к чему бы это? А к тому, что на заре бурной молодости системы для каждой табличке были свои сиквенсы. Конечно, со временем это безобразие поправили, но старые ключи всё равно остались. Более того, они корнями проросли по внешним ключам с другими таблицам. Фиксируем вторую проблему, связанную со сквозной нумерацией всех справочников.

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

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

Ну мы же молодцы, мы и это победили))) Теперь, попивая чай из своей кружки, начинаешь дискутировать с другими коллегами на тему, что им приходилось решать, и понимаешь, что список проблем пополняется. В обсуждении стоит вопрос как хранить версии одной и той же записи. Хочу оговорится, что версия, это не то, что укладывается в таблицу историчности. В историчности понятно, до такого-то числа было одно название, а начиная с этой даты актуальным становится другое. А в версионности подразумевается, что запись была сначала сохранена с ошибкой, а через несколько часов это поняли и её изменили, и нужно знать все состояния этой записи. Во-первых, здесь должно быть дробление на время, не только сутки. А во-вторых, такие следы нужны в случае разборок. Например, заполняли прайс, ошиблись, успели товар продать по такой цене, а потом поправили, но в конце дня случился дебаланс. Однако решение для таких ситуаций меня лично напрягло, предлагалась все такие изменения хранить в самой таблице. Не буду устраивать холивар на сколько так правильно, но для меня точно обозначилась пятая проблема, а именно хранение изменений записей.

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

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

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

Таблица nsi_type системная, заполняется по мере добавления новых справочников. Таблица nsi хранит ключи и системные поля. Заодно создаём собственный сиквенс и тем самым закрываем вторую проблему.

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

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

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

Теперь, пока не поздно, нужно вспомнить про грабли с номером «пять». Если начнём добавлять записи в созданную таблицу организаций, то это событие нужно где-то фиксировать.

А так же в пакет добавлена функция логирования.

Таким образом разрешена пятая проблема, теперь для любой записи НСИ можно посмотреть, что с ней происходило.

Пытаемся добавить туда организацию.

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

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

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

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

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

Применим к нашей таблице nsi_organization.

Функция nsi_organization_table очень полезна, потому как удовлетворяет нашим требованиям и окончательно уводит проблему номер четыре в прошлое.

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

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

Осталось дополнить пакет pkg_nsi обработкой этой таблицы.

И добавим кого-нибудь в эту таблицу.

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

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

Теперь присвоим соответствующие атрибуты.

Таким образом мы победим третью проблему.

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

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

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

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

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

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

Осталось только заполнить и собрать необходимые классификаторы.

Ой, как это не читабельно!

Следует не забывать, что кроме отношения включения (в том числе и древовидного), существует отношение пересечения, то есть кросс-таблиц. Здесь добавляется дополнительное условие проверки пересечения по времени.

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

Материал подготавливался на версии Oracle 18c, хотя нативное поддержание формата json уже присутствует в версии 12. Здесь ссылка с архивом скриптов.

Источник

Код обд нси где взять. Нормативно-справочная информация в составе единой информационной базы (НСИ). Смотреть что такое “НСИ” в других словарях

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

1. Историческое наследие

Эксперты НЦИТ «ИНТЕРТЕХ» по результатам анализа информационных систем, используемых в крупных компаниях и государственных структурах, пришли к следующим выводам:

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

В качестве решения указанных проблем ИНТЕРТЕХ предлагает создание Единой системы ведения НСИ, увязывающей в общекорпоративное информационное пространство всю нормативно-справочную информацию подразделений, дочерних предприятий и партнеров компании.

Для реализации этого решения необходимо:

Разработать и принять стандарты и регламенты ведения НСИ:

Использовать методику онтологической классификации и кодирования, разработанную специалистами ИНТЕРТЕХ.

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

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

Внедрить автоматизированную систему, обеспечивающую:

Ниже приведены основные этапы работ по созданию Единой системы ведения и управления НСИ.

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

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

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

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

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

6. Программное обеспечение

Ontologiс 4.6 широко используется многими крупнейшими российскими компаниями в качестве платформы для MDM-решений. На данной платформе разработаны и внедрены системы управления НСИ (MDM) в таких компаниях, как ТНК-BP, Татнефть, СИБУР, ИНТЕГРА, Норникель, Трансмашхолдинг, Транснефть, ГОЗНАК, Полюс-Золото, НОВАТЭК и др.

С учетом опыта таких внедрений, компания «ИНТЕРТЕХ» поставляет готовое типовое решение для системы управления НСИ .

ОСНОВНЫЕ ХАРАКТЕРИСТИКИ

6.1. Архитектура решения

Состав компонентов решения:

Используемое для сервера приложений программное обеспечение:

Используемое для сервера базы данных программное обеспечение:

Используемое на АРМ-ах пользователей, экспертов, администраторов ПО:

6.2. Функциональность системы

Функции поиска данных:

Функции экспорта и печати информации о записях справочника:

Функции пользователя по актуализации справочника:

Функции эксперта по ведению НСИ:

Функции администрирования системы:

6.3. Информационное наполнение

Решение поставляется с преднастроенной структурой справочников и классификаторов и загруженным демо-контентом. В состав входят:

КАСТОМНЫЕ СПРАВОЧНИКИ И КЛАССИФИКАТОРЫ:

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

6.4. Возможности интеграции

Средства интеграции решения на платформе ONTOLOGIC 4.6 позволяют настраивать различные сценарии репликации обновлений данных из ЕС НСИ в прикладные системы заказчика с использованием интеграционных шин (SAP PI/XI, IBM WebSphere, и др.) или файлового обмена.

ИНТЕРТЕХ является разработчиком и владельцем уникальной методологии и технологии построения классификаторов корпоративного уровня, программного обеспечения «ОК» и наполненных баз данных, что позволяет комплексно «под ключ» решить все описанные выше проблемы.

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

ИНТЕРТЕХ имеет реальные внедрения своих решений по построению Единых систем ведения НСИ, классификации и кодирования (онтологического классификатор).

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

ИНТЕРТЕХ внедрил в свой производственный процесс и использует систему менеджмента качества в полном соответствии с требованиям ГОСТ Р ИСО 9001-2001.

ИНТЕРТЕХ ведет активное взаимодействие и координацию работ в области классификации с Госстандартом РФ, Минэкономразвития РФ, Минэнерго РФ, Минпромнауки РФ, ТПП РФ.

ИНТЕРТЕХ имеет все необходимые лицензии (ФАПСИ и Гостехкомиссии при Президенте РФ) на право работы с системами защиты информации на территории РФ.

Разработанные ИНТЕРТЕХ системы и решения прошли экспертизу и имеют положительные отзывы ряда министерств и ведомств, в том числе Госстандарта РФ, Минпромнауки РФ, Высшей школы экономики, ТПП РФ, РСПП, Российской Академии государственной службы (РАГС) при Президенте РФ и т.д.

В центральном офисе ОАО «Газпром» состоялось очередное заседание Координационного комитета по информатизации под руководством заместителя Председателя Правления — начальника Финансово-экономического департамента Андрея Круглова.

В работе заседания приняли участие члены Координационного комитета по информатизации, руководители Управляющих комитетов проектов по информатизации, руководители и специалисты структурных подразделений ОАО «Газпром» и профильных дочерних обществ ООО «Информгаз» и ЗАО «Информгазинвест».

На заседании были рассмотрены результаты работы по проектам создания:

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

По итогам заседания управляющим комитетам проектов поручено обеспечить ввод систем в постоянную эксплуатацию в установленные Планом реализации Стратегии информатизации ОАО «Газпром» сроки.

Справка

Стратегия информатизации ОАО «Газпром» утверждена Постановлением Правления ОАО «Газпром» 17 января 2008 года. Стратегия определяет ключевые направления развития в ОАО «Газпром» информационных технологий, обеспечивающих достижение стратегических целей компании.

В рамках первого этапа реализации Стратегии работы ведутся согласно плану, утвержденному на расширенном заседании Координационного комитета по информатизации, состоявшемся 20 июня 2008 года под руководством Председателя Правления ОАО «Газпром» Алексея Миллера.

Целью построения Отраслевого банка данных документарной и фактографической нормативно-справочной информации (ОБД НСИ) в ОАО «Газпром» является создание основы для формирования единого информационного пространства за счет применения единой методологии, регламентов и инструментов ведения НСИ. В основу реализации ОБД НСИ легло использование специализированных программных продуктов SAP MDM, SAP XI, SAP Enterprise Portal. Основным результатом создания ОБД НСИ станет обеспечение целостной и непротиворечивой НСИ для формирования корпоративной отчетности Группы Газпром.

Целями проекта построения внутрикорпоративного интернет-портала ОАО«Газпром» являются: создание единой среды для доступа к информационно — управляющим системам, реализуемым на базе различных программных платформ, и информационно-справочным системам ОАО «Газпром»; обеспечение доступа пользователей к информационным ресурсам вне зависимости от их местонахождения в соответствии с регламентами разграничения доступа; создание единой технологической платформы обеспечения коллективной работы различных групп пользователей. В основу реализации интернет-портала легло использование специализированного программного продукта SAP Enterprise Portal. Основным результатом создания портала станет технологическая интеграция компонентов целевой системной архитектуры и интеграция доступа к их ресурсам пользователей ОАО «Газпром» и его дочерних обществ.

Целью проекта создания Информационной системы «Транспорт, подземное хранение и использование газа, объекты энергетики» ОАО «Газпром» является повышение эффективности информационного обеспечения Департамента по транспортировке, подземному хранению и использованию газа ОАО «Газпром» и снижение трудоемкости процесса сбора, обработки и хранения данных о деятельности дочерних обществ и организаций ОАО «Газпром» по виду деятельности «транспортировка газа и газового конденсата». В основу реализации системы легло использование программных продуктов SAP BI и SAP Enterprise Portal. Результатом реализации проекта должно стать решение следующих задач: автоматизация процесса сбора, обработки и хранения данных; уточнение методик заполнения шаблонов отчетных форм и регламентов предоставления данных.

Требование обеспечения взаимодействия и унификации различных прикладных систем бизнес-процессов протекающих на http://en.wikipedia.org/wiki/Service_oriented_architecture предприятиях и в различных организациях, консолидации отчетной документации, приводит к необходимости построения системы нормативно-справочной информации. Систему нормативной справочной информации образуют группы объектов, построенных на общероссийских, отраслевых и корпоративных (внутренних) [классификаторах] и справочниках.

Основные проблемы НСИ в корпоративных информационных системах:

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

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

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

Термин НСИ имеет советское происхождение, хотя чёткого определения в СССР введено не было. На западе более подходящим аналогом НСИ является Master Data или Master Referenced Data, сутью которых является не-транзакционная нормализованная справочная информация (каталоги) и классификаторы (иерархии). Таким образом Master Data (Мастер данные) можно рассматривать только как подмножество понятия НСИ.

Системы Управления Справочниками можно приравнять к международному понятию Master Data Management (MDM), которые могут рассматриваться как часть Service-Oriented Аrchitecture (SOA).

Принципиальным является, что словари, стандарты, правила, нормативы, которые обыкновенно включают в понятие НСИ, не являются объектами систем MDM.

См. также

Ссылки

Смотреть что такое “НСИ” в других словарях:

НСИ Рунавик Полное название Nes Sóknar Ítróttarfelag Runavík Основан 1957 Стадион Рунавик … Википедия

Полное название Nes Sóknar Ítróttarfelag Runavík Основан 1957 Стадион Рунавик … Википедия

НСИ Рунавик Полное название … Википедия

Нескл., мн. (ед. манси, нескл., м. и ж.). Народ, составляющий коренное население Ханты Мансийского автономного округа РСФСР, а также лица, относящиеся к этому народу … Малый академический словарь

И грунши, груси, нескл., м. и ж … Русское словесное ударение

Манси, нескл., м. и ж. (народ) … Русское словесное ударение

Книги

Количество лайков и подписчиков – показатель популярности страницы.

Легендарный игрок и лучший снайпер, также профессиональным игроком всех.

Думаем, что многие сталкивались с такими игроками CSS v34 использующие.

Источник