Для начала отвечу не заданные непосредственно мне вопросы:
реклама
Для начала отвечу не заданные непосредственно мне вопросы: Рассмотрим иерархический код и «безранговое дерево». Аналитическая работа прикладных приложений с «простым идентификатором БД» будет очень сложна. Хотелось бы узнать, как Альберт Гаилевич предлагает получить ответ на часто задаваемый вопрос: «Сколько жителей в районе города?» или «Сколько ветеранов живет на улице …(такой то)?». Кроме того при частом использовании, мантисса может дать специалисту информацию и без дополнительного запроса. (выделено мною) Видно что Елена Михайловна и сама видит ответ на собственный вопрос, а ответ состоит именно в том что идентификация данных (или их «кодирование») при размещении в различных хранилищах и статистические запросы к данным являются совершенно несовместимыми разноуровневыми задачами. Мною, естественно, предполагается ответ о count-запросе в актуальной базе данных с необходимыми условиями задачи. Относительно древовидного справочника – это вопрос реализации. Существенной разницы нет, хотя древовидный справочник, наверное, более информативен. Однако, и здесь также есть противоречие, между разными потребностями. Например, в почтовом адресе никак не используется район города, но в аналитической работе, очень часто требуется именно разделение прикладных данных по районам города. Таким образом, улицу, проходящую по нескольким районам, невозможно отобразить в древовидном справочнике с районом, и район приходится использовать как атрибут элемента адреса, но при этом теряется информативность самого дерева. Думаю мой ответ здесь вызовет «бурю эмоций» в виду не понимания определённых технических тонкостей данной ситуации. Районы города не являются древовидными элементами (строго иерархическими), районы города конечно же «подчиняются» в дереве адресному элементу с ролью «Город», но они не являются единственными родительскими элементами для элементов с ролью «Улица». Данная структура данных является не иерархической, а сетевой. В интеграционном хранилище данных ЦКРД было разработано техническое решение, позволяющее хранить сложно иерархические данные в сетевой структуре, в том числе с разделением сети на ролевые деревья. В данном случае адресные элементы «Район города» и «Улица», являются элементами одной сети, но формируют разные древовидные ролевые отношения. Считаю обсуждение данной «проблемы» преждевременной и бессмысленной так как участие «Района города» в формировании адреса Объекта Недвижимости отсутствует. Запросы по прикладным БД с использованием адресного идентификатора существенно проще и быстрее выполняются. Выборки с использованием «дерева», как уже говорилось, существенно более сложны, и более затратны по времени. Здесь позволю с Вами «не согласится», а точнее указать что скорость выборки данных напрямую зависит от архитектуры ORM-ядра и наличия соответствующих индексов в БД. Да, рекурсивная выборка данных по иерархии сложнее, чем работа с линейным списком, но это не повод «всё выпрямить до линейных списков и забыть об отношениях объектов». О невозможности применения кодирования динамически изменяющихся справочников я уже упоминал. Потому «довод» в «пользу» скорости выборки относительно довода о невозможности кодирования динамически изменяющихся структур не выглядит убедительным. Вижу со стороны Елены Михайловны попытку толи отстоять полезность работы с помощью каскадированных счётчиков (хотя их бесполезность демонстрируют КЛАДР и ОКАТО) толи бесполезность идентификации данных. Если в Вашей работе жизненно необходимо использовать не сложные запросы к БД, или каскады запросов (многоступенчатая обработка данных), а именно «упрощающую» систему каскадированных счётчиков, то тогда вопрос: А зачем идентифицировать данные каскадными кодами? Почему Вы умоляете необходимость идентификации данных, необходимостью их последующего анализа? И всё-таки: процессы идентификации и анализа данных совершенно независимы друг от друга, и попытки «сразу решить сто проблем» тут не уместны. Если копирование – то мы получаем другие идентификаторы БД со всеми вытекающими последствиями для прикладных АС, если переносом – то теряем историю (либо ведением отдельной истории, что не упрощает задачу). О каких «упрощениях задачи» идёт речь? Я не сторонник «простых решений», и не пропагандирую «простое решение» типа КЛАДРа и ОКАТО при котором актуальные данные в справочниках перемешаны с неактуальными данными и с данными вообще не соответствующим действительности. Простой пример: Улица Воровского переименована в г.Уфе в Проспект Салавата Юлаева. На данный момент в КЛАДРе есть улица Воровского (историзм что ли?), проспект Салавата Юлаева (актуальные данные), проспект С. Юлаева (дезинформация), проспект Юлаева (дезинформация), проспект Салавата (дезинформация). Ведение системы историзма, строго отделяющего актуальные данные от устаревших, жизненно необходимо и игнорирование данной обязательной функциональности системы недопустимо. Проблема обеспечения достоверности данных, обязывает использовать данные из первоисточника, а не по системе «глухого телефона». Проблему входного контроля, на наш взгляд, лучше решать специальным приложением, в нашем случае – клиентским приложением АР, которое в принципе не позволяет ввести адрес неправильно, и в тоже время позволяет облегчить его ввод за счет настроек по умолчанию. Проблему входного контроля тоже надо решать «всем миром», а точнее на всех уровнях интеграции данных. Заодно предостерегу участников дискуссии от поспешности выводов или игнорирования аспектов интеграционного уровня взаимодействия ИС, а также поспешности выводов относительно их «простоты». Интеграционная задача зачастую многими воспринимается как одноразовая конвертация данных из «старой» системы в новую и более крупную. Так же поверхностный подход а анализу глубины этой проблемы позволяет очень многим уважаемым людям заявлять, например, о простом решении написать крупную «корпоративную» (или пусть муниципальную) ИС, и затолкать в неё все объекты, все техпроцессы и т.д. Такой подход давно устарел, и совершенно не соответствует действительности. К тому же он предполагает делегирование разработки некоему «самому умному» разработчику, отнимая хлеб у других разработчиков ИС. К тому же всётаки повторюсь, что различные ИС, разработанные под различные задачи, являются необходимыми инструментами в работе, и имеют различную структуру данных. А потому у многих современных предприятий встаёт вопрос именно об интеграции (и синхронизации относительно первоисточника) неких «базовых» общеиспользуемых данных. Перед некоторыми крупными и опытными фирмами вообще ставятся задачи межплатформенной интеграции (попытки интеграции приложений на уровне операционных систем SUSE Linux и Windows Server). Системы кодификации и были разработаны, в том числе, для задач анализа информации. Для чего были разработаны системы кодирования в данном контексте не стоит упоминать, в виду их полной бесполезности в анализе динамически изменяющихся данных. Наличие мнимой возможности получить количество подэлементов в дереве путём «одного взгляда» на последний присвоенный код или какую то часть кода (не всегда уже актуального кода!) вместо полноценного запроса к базе не позволяет смешивать задачи идентификации данных и их статистического (или любого другого) анализа. Приведу пример. Вы сделали «список» (линейный список элементов одного уровня) и закодировали его от 001 до 100. Прошло время. Элементы 050 и 060 прекратили свой жизненный цикл. Сколько элементов осталось в вашем списке? Ответ 100. А что делать если у Вас появился новый адресный элемент? Какой код ему присвоить? 101? А адресных элементов в Вашем списке теперь сколько? Ну пусть даже в Вашем списке всё нормально «исправлено» и 050, 060 элементы отсутствуют, но последний присвоенный код всё равно – 101, адресных элементов у Вас 99, а в ИС которые имеют копию вашего ресурса сколько? Поэтому все эти системы каскадированных счётчиков являются всего лишь одним большим источником ошибок для иерархических справочников с наличием динамики. Не надо думать что централизованный АР решит проблемы, это наоборот их только создаст. Это решение приводит к принципиальной неработоспособности систем ведущих АР… Строить систему, функционирование которой жестко завязано на линии связи и доступ к единому центру выдачи идентификаторов? Никаких жёстких связей на линии связи нет, для синхронизации данных между системами обязан использоваться интеграционный подход к регламентации и управлению сеансами обмена данными на всех уровнях, т.е. асинхронная обработка данных, на основе сеансов «обмена сообщениями». Поэтому я, также как и С.А Трофимов, не вижу в этом необходимости. Концепция должна строится на физической независимости любого уровня АР от выше- и ниже- стоящего. Но, при общей логической структуре, идеологической и стандартизованной платформе (о чем скажу дальше). Здесь мне придётся нарисовать для Вас «пару» схем, дабы объяснить пропагандируемый мною способ взаимодействия разноуровневых ИС. Заодно придётся продемонстрировать и явные недостатки децентрализованной схемы, не решаемые «идеологическими» способами управления. Объекты – да. Внешний интерфейс – то с чем оперирует сторонний пользователь системы, должен быть объектом, причем стандартизованным, а вот внутренняя реализация – на усмотрение исполнителя, но соблюдением установленного стандарта. Какого исполнителя? Несколькими строками выше Вы упоминали «готовый» АРМ. Кстати на счёт «готового» АРМа – пользоваться ещё одним АРМом никто не станет вообще (итак специалистам приходится в нескольких ИС работать, а тут ещё один). Функции интеграции данных (а значит отслеживание их актуального состояния и выявление произведённых изменений в достоверном первоисточнике) необходимо заниматься техническим специалистам, занимающимся вопросами интеграции данных с информационными системами различного уровня. Такими специалистами в г. Уфе являемся мы, специалисты МУП «МИТЦ», и имеем рабочий интеграционный завершённый проект, такой как ЦКРД. Поэтому наша точка зрения такова: «Да» – объектному подходу в приложении, «Но» – реляционная модель в хранении данных. Такое сочетание прекрасно себя зарекомендовало у нас на протяжении нескольких лет (и опять же, реализаций такого похода достаточно много). Спора нет, и ничего противоречащее данному подходу мною не выдвигалось. Наше ЦКРД также основано на ORM-ядре Data Manipulation Core, хранящее данные в реляционной базе данных, но осуществляющей преобразование хранимых данных в объектное представление (и наоборот). Ядро ведёт обязательный не отключаемый полный системный историзм данных, что позволяет полностью отделить актуальные данные от неактуальных, следить за их версиями и т.д. Развитая система настройки прав доступа позволяет отказывать в доступе к изменению данных всем, кто не является первоисточником (ответственным владельцем) этих данных. Проблема заключается именно в том, что в ИС приходится иметь дело не только с данными, взятыми из первоисточника (адресный реестр из Главархитектуры), но и с данными об адресах, за которые Главархитектура муниципального образования ответственности не несёт (другие регионы, почтовые абонентские ящики, и т.д.). …Египет: «использование XML в качестве метаязыка представления данных и XSL в качестве средства их трансформации для представления» Соглашусь с египтянами на все 100%. Здесь позволю себе «спустить Вас на землю» заявив то, что технология преобразования данных XSLT является технологией одностороннего преобразования данных. Таким образом, данная технология является лишь возможностью преобразования данных в XML формате (+ обязательно в подходящей структуре данных) например в формат XHTML. Обратной конвертации данных на данной технологии Вы никак не добьётесь. Нами данная технология признана технологией, не позволяющей организовать взаимообратное преобразование данных, необходимое для интеграции различных ИС и их взаимодействия в обе стороны. Поэтому в МУП «МИТЦ» разработана собственная специальная технология прямой и обратной конвертации данных различных форматов. Ещё более спорным является решение хранения метаданных в XML’е. XML – это не визуальная среда программирования, типа Microsoft Visual Studio и возможности, предоставляемые визуальными средами программирования (наследование, интерфейсы, генерики и многое другое) сравнивать с XML-файлом просто бессмысленно. К сожалению ни одна из ссылок на сайт http://www.govtalk.gov.uk/ не открылась. Передача данных в единый центр и там создание единого справочника – этому тоже есть пример – КЛАДР. Не так давно это было – выходит новая редакция – стоны пользователей которые его используют – все привязки адресов потеряны… На каждом уровне должна быть своя зона ответственности, не надо все тянуть наверх… Создание РИПД – попытка создания распределенной системы – уже хорошо … Здесь я вижу подмешивания одних понятий с другими, и как следствие «замыливание» проблематики. Ещё раз повторюсь, КЛАДР содержит в себе актуальные, неактуальные и не соответствующие действительности данные, так как функция ответственного ведения данных была делегирована с муниципального уровня на федеральный. Централизованно-распределённый подход не только не мешает ответственному ведению данных «на местах», а позволяет вести все эти изменения в едином ключе, с чётким распределением прав и входным контролем за размещаемыми в «Едином реестре» данными. В главе «Преимущества централизованно-распределенных систем» Альберт Гаилевич приводит примеры и преимущества этих систем на основе сильно централизованных ведомств – силовых, пенсионного фонда, промышленных – т.е жестко организованных структур, где эти системы работают внутри этих структур, и только на эти структуры. Там несомненно нужна подобная организация. Но даже в них должны быть открытые, опубликованные, интерфейсы для взаимодействия систем между собой. А создавая публичную систему – а АР, это именно публичная система, на мой взгляд, ее нельзя строить на принципах ведомственной. Такая система должна быть распределенной, построенной на открытых стандартах (интерфейсах). Иначе очень вероятно, что она будет похоронена теми же проблемами – устареванием технологий, устареванием ПО, задержки с обновлением и др. Позволю себе проинформировать участников дискуссии о том, что Роснедвижимостью в данный момент предпринимаются попытки «выверки КЛАДРа», в целях ведения ЕГРОН. Так что вполне возможно АИС АР РФ будет находиться в их ведомстве. Централизация ведения АР РФ не просто не встанет как вопрос внутри Роснедвижимости, а сам собою будет ими принят как подреестр ЕГРОН. Фактически Адресный реестр РФ представляет собой на данный момент реестр зданий с адресами. Реестр земель уже ведётся сотрудниками Роснедвижимости в виде централизованного ресурса ЕГРЗ. Я постарался ответить на все вопросы, ответы на которые мог дать. Посоветую участникам дискуссии читать документы не в качестве «повода для битья», а с попыткой понимая заложенных в них принципов. Понимаю что для полного понимания некоторых «новых» (и не новых, но не совсем понятных) принципов требуются усилия воли и время, а также некоторые разъяснения. Теперь, я, как и обещал, попытаюсь продемонстрировать различия между централизованно-распределённой и децентрализовано-распределённой схемами «взаимодействия» (во втором случае взаимодействие вообще отсутствует и каждый живёт своей свободной и «беззаботной» жизнью). ФИС РИС МИС МИС РИС МИС МИС МИС РИС МИС МИС МИС МИС Схема 1 Централизованная РИС МИС МИС РИС МИС МИС МИС РИС МИС МИС МИС МИС Схема 2.1 Децентрализованная без федерального центра РИС МИС МИС РИС МИС МИС МИС РИС МИС МИС МИС МИС Схема 2.2 Полностью децентрализованная В принципе сразу уже всем видно отсутствие «головы» в данных схемах, что означает полный хаос и полное отсутствие какого-либо контроля. Если в схеме 2.1 Региональные ИС (РИС) могут осуществлять какой-либо контроль за данными, размещаемыми из Муниципальных ИС (МИС), то в схеме 2.2 даже и этой функции нет. Теперь представьте что я – злоумышленник (термин по ГОСТу), и знаю все стандарты, связанные с АИС АР РФ, теперь я решил «пошутить» и разместить общедоступную информацию назвав её Адресным реестром Регионального уровня «Адресный реестр Республики Казантип». Что мешает мне это сделать? РИС МИС МИС РИС МИС МИС МИС РИС МИС МИС МИС РИС МИС МИС Схема 2.1.1 Уровень ФИС отсутствует, что позволяет всем и вся, зная определённые стандарты, и с фактическим отсутствием каких-либо технологий защиты информации размещать злоумышленникам всё что заблагорассудится. Теперь рассмотрим более удручающую ситуацию, когда злоумышленник создал собственный сайт в Интернете, являющийся чьей-нибудь копией официального портала, и «немного» изменил её содержимое. Так как единого контролирующего Федерального информационного центра НЕТ (а заодно и нет регионального контроля), то злоумышленник вполне может объявить свой сайт «официальным», и опровергнуть данное утверждение будет некому. РИС МИС МИС РИС МИС МИС МИС РИС МИС МИС МИС МИС Схема 2.2.1 Во всех децентрализованных схемах отсутствие вышестоящего и головного центра не позволит установить достоверность ресурса, размещаемого на чьём-либо «официальном» (выдаваемого злоумышленником за официальный) портале. Сразу предупрежу возможные доводы об «электронной подписи». ЭЦП – не панацея защиты информации. Гарантирую, что практически никто не станет проверять каждый раз ЭЦП поставленную Вами перед очередным выкладыванием обновлённой версии Ваших данных. Да и проверка Вашей ЭЦП предполагает доверительные отношения с Вашим Удостоверяющим Центром. Получение достоверных данных является целесообразным из одного Единого Государственного Реестра, а не из кучи «официальных» сайтов, и не по запросу из федерального центра к Вашему ресурсу, а по интеграционной технологии восходящих и нисходящих потоков обновлений (возможно применение технологий горизонтального масштабирования ИС). Предлагаю заодно посмотреть реализацию портала http://egrul.nalog.ru/ информация в котором обновляется с задержкой на 2 недели, но обновляется по централизованнораспределённой схеме. Да и такой ресурс, как Единый Государственный Реестр Юридических Лиц, всё-таки является централизованным. Ещё раз напомню что Роснедвижимость занимается вопросом ведения Адресного реестра Российской Федерации, и реализация централизованной схемы взаимодействия не представляет никаких организационных трудностей (но есть большой ряд технических трудностей и некоторые непонимание технических тонкостей со стороны Роснедвижимости при работе в сфере интеграции ресурсов). Задачами федерального центра в централизованной схеме взаимодействия не является ведение Единого Государственного Реестра за всех (как это делается с КЛАДРом и ОКАТО), а управление синхронизацией и обновлением единого ресурса, на интегрирующей централизованно-распределённой технологии, позволяющей конечному исполнителю, отвечающему за ведение этого ресурса на месте (специалисту Главархитектуры в конечном итоге), вносить изменения (а также «удалять» устаревшие данные) при наличии и подтверждении его прав доступа к данному ответственному ресурсу, или прав предприятия, осуществляющего интеграцию данного ресурса, и отвечающего за преобразование (из ИС Главархитектуры в «стандарт» или в АИС АР РФ) и транзит данных (в Уфе это МУП «МИТЦ» и интегрирующая ИС ЦКРД). Удручает тот факт, что участники дискуссии позволяют себе пренебрегать или даже полностью игнорировать аспекты достоверности (отсутствия дезинформации) и безопасности ресурсов. Заранее извинюсь перед участниками дискуссии за то, что в силу ряда не зависящих от меня обстоятельств не смогу принять участие в очной дискуссии в г. Череповце. С уважением, архитектор проекта ЦКРД, системный аналитик, ведущий программист Шараев Альберт Гаилевич.
