Гп нси что такое

НОРМАТИВНО-СПРАВОЧНАЯ ИНФОРМАЦИЯ

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

Реестр абонентов (юридические и физические лица, ГП, ТСО, объекты теплогенерации);
КЛАДР (классификатор адресов Российской Федерации);
Справочник видов собственности;
Справочник ОКВЭД (Общероссийский классификатор видов экономической деятельности);
Региональные справочники нормативов потребления электроэнергии;
Справочник моделей приборов учета, трансформаторов тока и напряжения;
Справочник материалов и оборудования;
и многие другие.

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

Модели приборов учета

Справочник «Модели приборов учета» предназначен для информационных данных о приборах учета, внесенных в Госреестр. Технические характеристики приборов учета заносятся по данным из «Паспорта прибора учета».

Нормативы потребления электроэнергии

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

Справочник «КЛАДР» предназначен для внесения/хранения информации по адресам (областям, районам, нас. пунктам, улицам и т.д.).
Для добавления/редактирования/удаления элементов справочника организован механизм создания заявок, которые централизованно по всем подразделениям согласовываются единым центром компетенции.

В СОБИ у руководителя нет раздела администрирование

На сайте ГМУ авторизация стала проходить через подсистему обеспечения информационной безопасности Федерального казначейства РФ (СОБИ). После этого обновления у ряда сотрудников пропала возможность работать в ГМУ — пользователь заблокирован. В СОБИ у всех пользователей почта подтверждена и авторизация проходит успешно, но слетели права. Как выяснили необходимо раздать сотрудникам права на ГМУ в СОБИ, однако у руководителя организации в СОБИ нет раздела администрирование, вследствие чего не возможно согласовать заявку на добавление прав.

ТП ГМУ дала неясный ответ: Вам необходимо обратиться в ГП НСИ. У ГРО нет прав ГРО в связи с расхождение реестров. При этом в ГП НСИ руководитель указа верно.

Кто нибудь сталкивался с таким, как быть в этой ситуации?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 2046
Спасибо получено: 272

19 окт 2021 11:13 #19348 от Gvinpin
Gvinpin ответил в теме В СОБИ у руководителя нет раздела администрирование

alexkarkach пишет: у руководителя организации в СОБИ нет раздела администрирование,

В ЕГРЮЛ, Сводном реестре, регистрационных данных сайта ГМУ данные о руководителе актуальны и корректны?

______________________________
лучше уже было

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 4
Спасибо получено: 0

21 окт 2021 10:26 — 21 окт 2021 11:16 #19357 от alexkarkach
alexkarkach ответил в теме В СОБИ у руководителя нет раздела администрирование

alexkarkach пишет: у руководителя организации в СОБИ нет раздела администрирование,

В ЕГРЮЛ, Сводном реестре, регистрационных данных сайта ГМУ данные о руководителе актуальны и корректны?

Да, руководитель актуальный в ГМУ и сводном реестре.
Мы филиал ФГБУ ФКП, поэтому по ЕГРЮЛ бьется ЦА и соответственно указан руководитель ЦА, руководители филиалов как я понял там не указываются.
ТП Электронного бюджета (к ним относится ГП НСИ) при телефонном разговоре подтвердила, что у них наш руководитель указан верно. Создали новый инцидент, посмотрим что ответят.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 4
Спасибо получено: 0

21 окт 2021 11:08 — 21 окт 2021 11:16 #19358 от alexkarkach
alexkarkach ответил в теме В СОБИ у руководителя нет раздела администрирование

Предполагаю, что ответ будет в духе того, что администрирование теперь есть только у руководителя ЦА, а филиалам не предусмотрено.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 2413
Спасибо получено: 405

21 окт 2021 11:40 — 21 окт 2021 11:42 #19359 от Alex_04
Alex_04 ответил в теме В СОБИ у руководителя нет раздела администрирование

alexkarkach пишет: у руководителя организации в СОБИ нет раздела администрирование

О каком именно рук-ле Вы писали изначально — ЦА или филиала?

ТП ГМУ дала неясный ответ: Вам необходимо обратиться в ГП НСИ. У ГРО нет прав ГРО в связи с расхождение реестров. При этом в ГП НСИ руководитель указа верно.

Если Вы в первом посте имели в виду рук-ля филиала, то ответ ТП ГМУ становится более понятным. Ибо:

alexkarkach пишет: Предполагаю, что ответ будет в духе того, что администрирование теперь есть только у руководителя ЦА, а филиалам не предусмотрено.

+1 — скорей всего так и будет.
«Мы будем жить плохо, но недолго.» (© Черномырдин В.С.)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 4
Спасибо получено: 0

21 окт 2021 12:00 #19360 от alexkarkach
alexkarkach ответил в теме В СОБИ у руководителя нет раздела администрирование

О каком именно рук-ле Вы писали изначально — ЦА или филиала?

Руководитель филиала

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 6
Спасибо получено: 0

12 нояб 2021 10:14 #19502 от freud
freud ответил в теме В СОБИ у руководителя нет раздела администрирование

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

от имени руководителя заходил
sobi.cert.roskazna.ru/
права/ полномочии даны

дальше какие действия где эта заявка, как ее подтвердить если нет вкладки администрирование теперь
в каком «интуитивном» месте ее искать

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 2413
Спасибо получено: 405

12 нояб 2021 12:01 — 12 нояб 2021 12:17 #19503 от Alex_04
Alex_04 ответил в теме В СОБИ у руководителя нет раздела администрирование

Здравствуйте. По-моему, Вы смешали в 1 кучу совершенно разные 2 системы.

freud пишет: У пользователя
на bus gov
Ваша заявка на регистрацию отправлена на рассмотрение Администратору организации.
В случае положительного решения на указанный в заявке адрес электронной почты будет выслано уведомление, содержащее ссылку с временным паролем.

относится к сообщениям и действиям сайта ГМУ. Пользователь с правами «АДМИНИСТАТОР» из своего л/к на сайте ГМУ должен подтвердить заявку на регистрацию пользователя (уполномоченного специалиста — такая у него роль в серте ЭП).

от имени руководителя заходил
sobi.cert.roskazna.ru/
права/ полномочии даны
где эта заявка.

относится к действиям в ПОИБ СОБИ. НО они в данном случае не решают задачу регистрации пользователя ГМУ, т.к. заявка регистрации пользователя ушла не РЕГИСТРАТОРУ в ПОИБ СОБИ, а АДМИНИСТРАТОРУ в ГИС ГМУ!
Почему? Уверен (почти на все 100) — потому, что пользователь входил в ГМУ под сертом с ролями «ГМУ. » в нем, т.е. по старому. А без них ГМУ сама автоматом завернула бы его регистрацию через ПОИБ СОБИ. При этом были бы сообщения, прямо указывающие на дальнейшие действия именно в ПОИБ СОБИ, чтоб не промахнуться.

Теперь догадываетесь «в каком «интуитивном» месте ее искать»?

«Мы будем жить плохо, но недолго.» (© Черномырдин В.С.)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Меньше Больше

Сообщений: 137
Спасибо получено: 12

23 нояб 2021 08:21 #19584 от ViktorGRBS
ViktorGRBS ответил в теме В СОБИ у руководителя нет раздела администрирование

Alex_04 пишет: Здравствуйте. По-моему, Вы смешали в 1 кучу совершенно разные 2 системы.

freud пишет: У пользователя
на bus gov
Ваша заявка на регистрацию отправлена на рассмотрение Администратору организации.
В случае положительного решения на указанный в заявке адрес электронной почты будет выслано уведомление, содержащее ссылку с временным паролем.

от имени руководителя заходил
sobi.cert.roskazna.ru/
права/ полномочии даны
где эта заявка.

Теперь догадываетесь «в каком «интуитивном» месте ее искать»?

в ГМУ теперь нет Администратора. пишу как Бывший Администратор.
Точнее так: после перехода на аутентификацию и авторизацию через ПОИБ СОБИ, все роли назначаются в ПОИБ, раздел «Администрирование» в ЛК ГМУ ёк (не доступен).

Вложения:

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Приложение N 12. Перечень информационных систем персональных данных Министерства сельского хозяйства Российской Федерации

1. Система электронного документооборота Министерства сельского хозяйства Российской Федерации (СЭДО).

2. Автоматизированная система кадрового учета «Кадры» (АС «Кадры»).

3. Система предоставления государственных услуг в электронном виде Министерства сельского хозяйства Российской Федерации (ПК ЭГУ).

4. Федеральная государственная информационная система учета и регистрации тракторов, самоходных машин и прицепов к ним (ФГИС УСМТ).

5. Автоматизированная информационная система реестров, регистров и нормативно-справочной информации (АИС НСИ).

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

7. Информационная система планирования и контроля Государственной программы (ИС ПК ГП).

Механизмы интеграции внутрикорпоративных справочников Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Гудков К.С.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Ways of intra-corporate lookup tables integration in master data management systems

The problem of intra-corporate lookup tables integration in master data management systems is presented. The position of the problem in the general problem was indicated. Mathematical model of data unification and corresponding software program are implemented.

Текст научной работы на тему «Механизмы интеграции внутрикорпоративных справочников»

К. С. Гудков, инженер ФГУП «Государственный научно-исследовательский

институт авиационных систем», г. Москва

Механизмы интеграции внутрикорпоративных справочников

Задача создания корпоративной системы поддержки нормативно-справочной информации (КСП НСИ) рано или поздно встает перед любым предприятием [1]. Перед ее созданием необходимо разделить совокупность используемых справочников на две группы: справочники, содержимое которых не зависит от специфики деятельности предприятия, и внутрикорпоративные справочники, формируемые в процессе деятельности предприятия. Общий алгоритм работы со справочниками из первой группы приведен в [2]. Для успешного использования справочников из второй группы необходимо провести интеграцию используемых до внедрения КСП НСИ справочников и утвердить протокол их обновления в рамках КСП НСИ. Как и в работе [2], предполагается наличие в корпоративной информационной системе консолидированной базы данных нормативно-справочной информации. Тиражирование данных при помощи гетерогенной системы репликации данных остается таким же, как и в случае справочников из первой группы. Общий механизм управления нормативно-справочной информацией показан на рис. 1. К недостаткам существующих до внедрения КСП НСИ внутрикорпоративных справочников, которые следует учитывать при интеграции данных, следует отнести неполноту, неактуальность, а также возможную противоречи-

Сокеты поверх TCP/IP

Территориально удаленные участки Рис. 1. Механизм управления НСИ

вость содержащихся в них данных [3]. Цель настоящей статьи — подробный анализ процесса интеграции внутрикорпоративных справочников с решением наиболее типичных проблем, возникающих на практике. В рамках анализа будет приведена созданная для описания интеграции справочников математическая модель, описан реализующий ее программный продукт, приведены создаваемые с его помощью SQL-сценарии на языке Transact SQL. В предлагаемой математической модели использованы те же обозначения, что и в [2, 4]. Интеграция внутрикорпоративных справочников позволяет избежать финансовых потерь, связанных с неполнотой, неактуальностью и противоречивостью данных в исходных справочниках, повысить точность отчетных данных и принять более правильные управленческие решения.

Сравнение естественных и суррогатных первичных ключей

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

Первичный ключ (primary key) — это один или несколько атрибутов, которые уникально характеризуют кортеж отношения. Если используется несколько атрибутов, первичный ключ называется составным (composite primary key). Если первичный ключ полностью составлен из атрибутов, несущих смысловую нагрузку в рамках предметной области, он называется естественным (natural primary key). Если первичный ключ состоит из атрибутов, добавленных с целью уникальной идентификации кортежа и не несущих смысловой нагрузки в рамках предметной области, он называется суррогатным (artificial primary key). В большинстве практических задач естественный первичный ключ является составным, а суррогатный первич-

ный ключ — атомарным. При дальнейшем § сравнении имеется в виду именно такая ситуация. ^

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

• Сложности по написанию SQL-сценари-ев по добавлению и модификации записей таблиц (например, разработчики вынуждены использовать конструкции вида «where A.a1 = B.a1 and A.a2 = B.a2 and . A. an = B.An»). Они приводят к увеличению срока создания прикладного программного обеспечения и увеличивают вероятность возникновения ошибок в SQL-сценариях.

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

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

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

Изложим аргументы против использования суррогатных первичных ключей:

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

различные значения суррогатного ключа, а принципиально разные — одинаковые. Данный недостаток характерен для суррогатных первичных ключей на основе автоинкрементных полей или их аналогов. Его можно устранить путем использования при проектировании в последнее время набирающих популярность UUID (Universally Unique IDentifier) значений [5, 6].

• Несемантическое наименование полей, используемых в качестве суррогатных первичных ключей (например ID). В результате при запросах к базе данных возможно создание ложных, вводящих в заблуждение связей. В качестве примера приведем использование конструкции «where A.ID = B.ID», не несущей смысловой нагрузки. Возникновение подобной ситуации при использовании естественных первичных ключей значительно менее вероятно.

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

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

g могут быть показаны с использованием как

5 естественных, так и суррогатных первичных

=g Математическая модель

S^ Пусть необходимо объединить справоч-|= ники, у которых множество совпадающих ат-| рибутов включает естественный первичный ^ ключ. Введем следующие обозначения: | • R( A1. An, B1. Bm) — первое из объе-■§. диняемых отношений; & • S(D1. Dn ,C1. Ck) — второе из объеме диняемых отношений; | • Т(Д. An ,B1. Bm ,Cv. Ck) — результи-g рующее отношение. | Единственное отличие атрибутов A1. An и D1. Dn — это название. Естественный

первичный ключ — это некоторое подмножество атрибутов А1. An для отношения R и некоторое подмножество атрибутов D1. Dn для отношения S. Приведем алгоритм интеграции справочников R и S:

• Переименуем атрибуты D1. Dn отношения S в соответствующие им атрибуты из набора A1. An. При этом на основании объединения естественных первичных ключей отношений R и S можно утверждать, что существует естественный первичный ключ A1. А,,l < n для обоих отношений. Далее будем считать, что атрибуты перенумерованы в соответствии с естественным первичным ключом. Это допустимо, так как в реляционной модели данных кортежи считаются неупорядоченными.

• Выберем из отношения R те кортежи, для которых не существует соответствующих значений естественного первичного ключа А1. А, в отношении S. Соответствующий предикат обозначим С1, а оператор выбора — oc(R).

• Выберем из отношения S те кортежи, для которых не существуют соответствующие значения естественного первичного ключа А1. А, в отношении R. Соответствующий предикат обозначим C2, а оператор выбора — oc2(S).

• Возьмем декартово произведение полученного в результате переименования атрибутов D1. Dn отношения S и исходного отношения R: L(А1. An,B1. Bm,C1. Ck) = R(А. An,B. Bm)x S(аА. An,C. Ck).

• Выберем из отношения L те кортежи, для которых выполняются равенства R.A1 = S.A1, R.A2 = S.A2. R.A, = S.A,. Соответствующий предикат обозначим C3, а оператор выбора — оСз (L).

• Отношение T выражается посредством объединения операторов выбора следующим образом:

T (А. An,B. Bm C. Ck ) =

= Oc1 (R) UOc2(S) UOc3(L).

Общая формула, выражающая отношение T через отношения R и S, записывается так:

иас2^(А. Ап,с1. ск)(^Ц. Ц1 ,с1. ск))) и

Объединение справочников, в которых использованы суррогатные первичные ключи

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

• Удаление суррогатного первичного ключа из отношения Я.

• Удаление суррогатного первичного ключа из отношения S.

• Получение отношения Т аналогично ранее рассмотренному случаю:

т (А. АВ1. вт с. ск) =

• Добавление в отношение Т нового суррогатного первичного ключа.

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

Противоречия в данных

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

• Обнаружение противоречий в данных внутрикорпоративных справочников при помощи автоматизированных средств.

• Сбор экспертов в предметной области справочников, в которых были обнаружены противоречия.

• Разрешение противоречий исходя из специфики предметной области.

• Внесение изменений в исходные справочники с устранением противоречий.

• Интеграция справочников согласно алгоритмам, описанным в предыдущих разделах.

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

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

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

• SQL-сценарии для выполнения объединения переданных таблиц на языке Transact SQL. При реализации ПСИВС рассматривалась альтернатива: создание SQL-сцена-риев на заданном пользователем диалекте языка SQL или использование предварительной конвертации «ФОРМАТ СУБД — CSV — ФОРМАТ MS SQL». Было отдано предпочтение второму варианту. В результате перед объединением таблиц, находящихся под управлением СУБД, отличных от MS SQL Server, рекомендуется при помощи ПСИВС преобразовать их к формату MS SQL Server, а уже затем использовать основную функциональность ПСИВС для интеграции данных.

• Набор данных, соответствующий объединению переданных таблиц. При помощи всплывающего меню пользователь оп-

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

ределяется с действиями, которые необходимо выполнить над набором данных. В частности, предоставляется возможность его сохранения в различные форматы данных, в том числе CSV-формат.

• Созданная в заданной пользователем базе данных под управлением СУБД MS SQL Server таблица, соответствующая объединению переданных справочников.

Практический пример интеграции таблиц при помощи ПСИВС

Пусть необходимо объединить таблицу FirstTable (соответствует отношению R) и таблицу SecondTable (соответствует отношению S). В обеих таблицах использован имеющий идентичный смысл в данной предметной области составной первичный ключ (Primary1, Primary2). Атрибуты Attr1 и Attri-bute1 различаются только наименованием. Атрибуты Attribute2 и Attribute3 уникальны для первой таблицы, а атрибут Attr2 — для второй. Сценарии по созданию таблиц показаны в листинге 1, а их содержимое — в табл. 1 и 2.

В рассматриваемом практическом примере входными параметрами для ПСИВС являются:

• Параметры соединения с реляционной таблицей FirstTable, которая находится под управлением СУБД MS SQL Server.

• Параметры соединения с реляционной таблицей SecondTable, которая находится под управлением СУБД MS SQL Server.

• Список соответствий между полями FirstTable и SecondTable. Для рассматриваемого примера он состоит из одной строки вида Attr1=Attribute1.

Первая из объединяемых таблиц (FirstTable)

Primary1 Primary2 Attribute1 Attribute2 Attribute3

if isnull(objectproperty(object_id(‘dbo.FirstTable’) ,’IsTable’), -1) = 1

drop table [dbo].[FirstTable]

create table [dbo].[FirstTable] (

[Primary1] varchar(10) COLLATE Cyrillic_General_ CI_AS NOT NULL,

[Primary2] varchar(10) COLLATE Cyrillic_General_ CI_AS NOT NULL,

[Attribute1] int NULL,

[Attribute2] int NULL,

[Attribute3] int NULL);

alter table [dbo].[FirstTable]

add constraint[PK_FirstTable] primary key clustered ([Primaryi],

if isnull(objectproperty(object_id(‘dbo.SecondTable’ ),’IsTable’), -1) = 1

drop table [dbo].[SecondTable]

create table [dbo].[SecondTable] (

[Primary1] varchar(10) COLLATE Cyrillic_General_CI _AS NOT NULL,

[Primary2] varchar(10) COLLATE Cyrillic_General_CI _AS NOT NULL,

[Attr2] int ); NULL

alter table [dbo].[SecondTable]

add constraint[PK_SecondTable] primary key clustered ([Primary!],

Таблица 2 в качестве формата выходных данных было выбрано получение SQL-сценариев по объединению таблиц FirstTable и Sec-ondTable. Созданные для тестового примера SQL-сценарии показаны в листинге 2. Результаты показаны в табл. 3.

Код содержит следующие логические части:

• Объявление табличных переменных @FirstTable и @SecondTable. Перенос в них содержимого объединяемых справочников.

Primary1 Primary2 Attribute1 Attribute2 Attribute3 Attr2

2 1 4 96 7 NULL

3 1 8 NULL NULL 64

Вторая из объединяемых таблиц (SecondTable)

Primary1 Primary2 Attr1 Attr2

declare @FirstTable table(Primary1 varchar(10) Attribute1 int, Attribute2 int, Attribute3 int) declare @SecondTable table(Primary1 varchar(10) Attribute! int. Attr2 int)

Primary2 varchar(10) Primary2 varchar(10)

insert into @FirstTable

select Primaryl, Primary2, from «FirstTable»

Attribute!, Attribute2, Attribute3

insert into @SecondTable

select Primaryl, Primary2, Attrl as Attributel, Attr2 from «SecondTable»

select l.Primaryl, l.Primary2, l.Attributel, l.Attribute2, l.Attribute3, r.Attr2

from @FirstTable as l, @SecondTable as r

where (l.Primaryl = r.Primaryl) and (l.Primary2 = r.Primary2) union

select l.Primaryl, l.Primary2, l.Attributel, l.Attribute2, l.Attribute3, null as Attr2

from @FirstTable as l where not exists (select *

from @SecondTable as r

where (l.Primaryl = r.Primaryl) and (l.Primary2 = r.Primary2) )

select r.Primaryl, r.Primary2, r.Attributel, null as Attribute2, null as Attribute3, r.Attr2 from @SecondTable as r where not exists (select *

from @FirstTable as l

where (l.Primaryl = r.Primaryl) and (l.Primary2 = r.Primary2) )

• Первый DML оператор select: извлечение строк, содержащихся в обеих таблицах. В математической модели ему соответствует оператор выбора aC (L). В практическом примере он возвращает набор данных, состоящий из первых двух записей табл. 3.

• Второй DML оператор select: извлечение строк, содержащихся в первой таблице, но отсутствующих во второй таблице. В математической модели ему соответствует оператор выбора aC (R). В практическом примере он возвращает набор данных, состоящий из третьей записи табл. 3.

• Третий DML оператор select: извлечение строк, содержащихся во второй таблице, но отсутствующих в первой таблице. В математической модели ему соответствует оператор выбора aC (S). В практическом примере он возвращает набор данных, состоящий из четвертой записи табл. 3.

• Объединение результатов запросов union. В математической модели ему соответствует образование отношения T по формуле: T = aC (R)uoC (S)uoC (L). В практическом примере результатом объединения является набор данных, показанный в табл. 3.

Поддержка внутренних справочников в КБД НСИ

В результате работы ПСИВС в рамках консолидированной базы данных нормативно-справочной информации были созданы таблицы, соответствующие ранее используемым внутрикорпоративным справочникам. После их создания любое использование предыдущих справочников должно быть прекращено. В противном случае справочники в составе КБД НСИ рискуют оказаться еще одним набором справочников, находящимся в противоречиях с остальными и содержащим неполные и неактуальные данные. Так как внутренние справочники формируются в процессе деятельности предприятия, любые изменения в них должны вноситься специально назначенными экспертами предметной области, отвечающими за их поддержку. При этом в целях унификации алгоритмов работы с КБД НСИ рекомендуется тот же, что и в статье [2], механизм поддержки репликации посредством LRO-таблиц. Механизм распространения данных можно представить следующим образом:

На основании изменений в справочнике КБД НСИ drk при помощи триггеров формируется LRO-таблица изменений crk

. По известной связи между справочником § drk в составе КБД НСИ и справочником /го территориально удаленного участка s’m ^ формируется набор данных с^гп, содержащий изменения, которые необходимо внести в справочник локальной базы данных территориально удаленного участка s’т. В справочник slm вносятся изменения, соответствующие набору данных с^гп. Связь между сгк и с^т отражена в формуле:

cSm [ p — 1,p] = Oc (п

C\»‘A,A2..AN VHS(A1A2. A

При помощи р и р -1 пронумерованы моменты синхронизации данных между локальной базой данных /-го территориально удаленного участка и КБД НСИ. Набор данных с^гп[р-1,р] содержит только изменения, накопленные в промежутке между этими моментами. Оператор оСТтпе отвечает за выборку в таблице сгк изменений, произошедших между моментами времени р и р -1.

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

восстановления КБД НСИ из резервной копии данные ее справочника не будут согласованы с данными справочника территориально удаленного участка. Чтобы избежать возникновения этой проблемы, достаточно тиражировать только те данные, которые уже были сохранены в резервной копии. Тогда на момент разрушения данных, которые одновременно и были тиражированы, и не были сохранены, не будет, т. е. согласованность данных не нарушится. Оператор выбора ас, оператор проекции кАЛ А и оператор переименования р^д^ д) отвечают за связь между таблицами Сгк и .

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

этого и используются операторы aC

Гп нси что такое