Нси sap что это

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

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

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

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

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

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

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

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

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

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

Таблица 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. Здесь ссылка с архивом скриптов.

Источник

Управление справочными данными: аналитический обзор рынка

Андрей Андриченко К.т.н., директор по разработке ЗАО «SDI Solution».

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

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

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

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

Рис. 1. Дублирование и несогласованность справочных данных

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

Master Data Management

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

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

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

Рынок MDM — это новый, динамичный, наукоемкий и ненасыщенный рынок программного обеспечения, потребность в котором появилась в последние несколько лет. С финансовой точки зрения этот рынок неисчерпаем. По результатам анализа многочисленных статей и маркетинговых исследований, посвященных рынку MDM, можно сделать вывод о том, что его мировой объем составляет несколько миллиардов долларов с тенденцией роста 60% в год. Докризисная оценка объема рынка MDM­систем (согласно аналитическим отчетам Gartner) к 2012 году составляла около 3 млрд долл. Аналогичная оценка агентства Forrester Research вдвое выше — 6,7 млрд долл. (рис. 2).

Рис. 2. Объем рынка MDM-систем (докризисная оценка Gartner)

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

Рис. 3. Основные компоненты и службы MDM-системы

Стоимость выверки одной эталонной записи в среде MDM за рубежом составляет 10­15 долл., в нашей стране — порядка 2­5 долл. С учетом того, что объем дублируемой справочной информации на машиностроительном предприятии значителен, услуги по внедрению MDM могут превышать стоимость поставки программного обеспечения.

Основные характеристики

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

­ данные о продукции (Product Information Management, PIM),

­ данные о клиентах (Customer Data Integration, CDI),

­ данные о финансах, имуществе, поставщиках, сотрудниках и пр.;

­ операционные — ориентированы на применение информационных систем в текущей оперативной работе,

­ аналитические — направлены на аналитическую обработку накопленной информации,

­ коллаборативные — обеспечивают постоянное обновление и дополнение справочной информации разными пользователями, представляющими разные точки зрения на нее;

­ централизованная (transaction hub) — используется центральный реестр справочных данных, содержащий эталонные записи (золотая копия), c которыми синхронизируются базы систем — потребителей НСИ (рис. 4);

­ децентрализованная — «единый взгляд» на мастер­данные формируется на лету и существует лишь виртуально, хотя для потребителей это выглядит как единое хранилище НСИ. Выделяют две разновидности этой модели:

1) когда MDM­система может влиять на те или иные данные потребителей (registry style),

2) MDM­система никак не вмешивается в данные потребителей, а может лишь производить в них поиск (coexistence style);

­ смешанная — сочетание первых двух моделей для разных потребителей НСИ.

Кроме того, существенными характеристиками MDM­систем являются поддержка стандартов (OWL, STEP, ISO15926 и пр.), платформенность, поддержка SOA, наличие интеллектуальных средств, возможность обмена данными путем импорта­экспорта файлов.

Рис. 4. Парная синхронизация и «золотая копия»

Основные поставщики MDM­решений

В настоящее время в мире самое широкое распространение получили несколько информационных систем, позиционируемых как основа для решений Master Data Management. Сильнейшие игроки на этом рынке указаны в табл. 1.

Таблица 1. Сильнейшие игроки на рынке МДМ-решений

Производитель

Наименование MDM-решения

InfoSphere Master Data Management Server

Customer Data Hub (CDH)

Siebel Universal Customer Master (UCM)

Product Information Management (PIM)

Hyperion Data Relationship Management (DRM)

SAP NetWeaver Master Data Management (SAP MDM)

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

Таблица 2. Информационные системы для управления НСИ

Производитель

Наименование MDM-решения

Initiate Master Data Service

DataFlux CDI Solution

Enterworks Enable PIM, MDM

Discovery Platform — Master Data Management Module

GXS Product Information Manager

Heiler Product Manager

i2 Master Data Management

iWay Master Data Center (MDC)

Bulldog (Enterprise Dimension Manager, +EDM)

Kalido Master Data Management

QAD Product Information Management (QAD PIM)

Источник

Нси sap что это

Часовой пояс: UTC + 3 часа

Начинающий

Зарегистрирован:
Вс, апр 09 2006, 17:12
Сообщения: 2

Младший специалист

Зарегистрирован:
Ср, ноя 07 2007, 11:21
Сообщения: 97

Директор

Зарегистрирован:
Чт, авг 18 2005, 17:00
Сообщения: 1174
Откуда: РФ

Младший специалист

Зарегистрирован:
Ср, ноя 07 2007, 11:21
Сообщения: 97

Младший специалист

Зарегистрирован:
Ср, ноя 07 2007, 11:21
Сообщения: 97

Начинающий

Зарегистрирован:
Вт, июл 01 2008, 10:49
Сообщения: 1

Младший специалист

Зарегистрирован:
Ср, ноя 07 2007, 11:21
Сообщения: 97

Специалист

Зарегистрирован:
Пт, июн 24 2005, 15:50
Сообщения: 230

Менеджер

Зарегистрирован:
Вт, авг 09 2005, 21:20
Сообщения: 538

Почетный гуру

Зарегистрирован:
Вс, окт 17 2004, 11:34
Сообщения: 1543
Пол: Мужской

Менеджер

Зарегистрирован:
Вт, авг 09 2005, 21:20
Сообщения: 538

Логотип © 2006 Андрей Горшков
Поддержка: Кирилл Андреев, 2011-…

Источник