Что такое интеграция браузера

Обновлено: 02.07.2024

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

Содержание

Типы интеграции

Преимущества веб-интеграции

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

Коммерческое ПО для веб-интеграции

Связанные технологии

Примеры

Статьи

Веб-программирование
Распределённые вычисления
Парадигмы программирования

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое "Веб-интеграция" в других словарях:

Doom 3 — У этого термина существуют и другие значения, см. Doom (значения). Doom 3 Разработчик id So … Википедия

Mozilla Firefox — Запрос «Firefox» перенаправляется сюда; см. также другие значения … Википедия

Gemini (программа) — Gemini технологическая дорожная карта в Gemini 3.6 Тип управление проектами Разработчик CounterSoft Операционная система Windows Языки … Википедия

Список расширений Firefox — Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей … Википедия

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

На русском и английском есть куча материала про то, зачем нужны веб-сервисы, какие они бывают, как их спроектировать, есть прикольные кейсы. Но про то, как взаимодействовать с ними на практике, особенно на сложных корпоративных системах, я не нашел ничего исчерпывающего. А как показывает опыт, черт кроется именно в деталях и подпунктах, большинство из описанных в этой статье – мои собственные «шишки».

Представь, что тебе надо сделать такую штуку: в зависимости от ответа веб-сервиса, который угадывает зарплату человека, отобразить пользователю кнопку разного цвета. Скажем если зарплата до 20 тыс. рублей, ты делаешь красную кнопку, если от 20 до 100 тыс., то желтую, и если она больше 100 тыс., то зеленую. Казалось бы, что может быть проще! Но чтобы описать эту задачу для разработки и разобраться во всем самому, тебе будет не лишним обратить внимание на 15 разных вопросов, а если фича безумно важная, то еще на 8 других.

Ну чего, погнали, программа минимум:

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

Продовые и тестовые ссылки / адреса (англ. Endpoints PROD, QA / TEST). Веб-сервис доступен именно по этим адресам. Ссылка на тестовый контур будет полезна, чтобы проверить работу сервиса, не внося изменений и не нагружая прод. Ссылки очень похожи на адреса обычных сайтов по формату, часто в них будет содержаться слово “api”. Можно попробовать открыть их в браузере, и иногда что-то отобразится.

Аутентификация. Как мы будем авторизоваться в веб-сервисе, чтобы он нам отдал нужные данные? Тут много разных вариантов: по ключу API, токену, логину и паролю в теле запроса, бывают и другие.

Примеры запросов: что передавать в веб-сервис для разных случаев, чтобы получить нужные тебе данные? Все ли эти данные у тебя есть?

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

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

Характеристики полей: тип поля, обязательность и длина строки.

Тип поля. Надо следить, чтобы мы передавали в запросе поля в том же формате, который ожидает получить сервис. Самые частые кейсы тут: передаем число как строку текста “2007”, вместо 2007 и разные форматы дат и времени, к примеру Date “2007-01-01” вместо DateTime “2007-01-01 11:00:00”. Когда получаем ответ от сервиса, тоже лучше следить, что данные из ответа запроса приходят в том же типе/формате, который мы ожидаем, иначе их надо будет конвертировать (переводить) в нужный тип.

Обязательность полей – есть поля, без которых запрос не будет работать, а есть те, которые можно не передавать иногда. Если ты знаешь, что поле необязательное, но тебе его надо передавать по полученному примеру запроса, то можно обсудить с разработчиками сервиса, что будет если не передавать его, возможно оно лишнее и не надо его добывать откуда-то, чтобы положить в запрос. Для SOAP можно посмотреть обязательность полей в WSDL или в примере запроса, ищи зеленый текст <! -- Optional: -->. Для REST это можно посмотреть в Swagger, обозначается красной звездочкой.

Длина строк – лучше проверить, что строки текста, которые мы передаем в запросе не сожмутся. Для SOAP есть возможность посмотреть в WSDL мин / макс длину строк в символах, ищи поля minLenght / maxLength. Для REST длина строк определяется на стороне сервиса и обычно само собой подразумевается, что строки не сожмутся. Однако если ты делаешь важную фичу или передаешь текстовую строку длиной в абзац в поле, которое по смыслу должно быть коротким (Имя, Телефон, Адрес), лучше уточнить это у разработчиков сервиса.

Поведение твоей системы в случае ошибок от сервиса (англ. exception flow). Надо продумать, как реагировать на ошибки от сервиса, к примеру можно делать перезапросы по такому правилу: сервис запрашивается раз в 20 минут, суммарно до 10 раз, после чего забиваем.

Полностью проверь работу интеграции на PROD / QA контуре, если есть такая возможность. Обрати внимание, что на QA контуре часто бывают моки или заглушки – когда сервис возвращает в ответе одно и то же подстановочное значение вместо нормальной обработки запроса. Если веб-сервис должен что-то сделать в другой системе, проверь, что это целевое действие выполнено, покажи запросы владельцу сервиса. На практике довольно часто всплывают проблемы именно на этом этапе.

Нагрузка. Обсуди с владельцем сервиса частотность вызова его сервиса, изменение нагрузки в течение суток / недели, а также ее потенциальные изменения в будущем.

Делать ли логирование запроса и ответа. Есть много плюсов: можно отслеживать баги, фрод, смотреть сколько было запросов сервиса суммарно.

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

Левел 2. Эти моменты лучше проверить, если фича важная:

Доступность сервиса в зависимости от времени. Если у сервиса есть “часы пик” во время которых он становится менее доступным, следует это учесть во время планирования работы с ним: предупредить пользователей, внимательно продумать реакцию на таймаут и ошибки в ответах.

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

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

Меняется ли структура ответа в зависимости от параметров запроса? К примеру, в запросе есть параметр “strategy”, в зависимости от которого в ответе возвращается разное число параметров. Наша система должна учитывать это.

Логика обработки ответа. Если ты меняешь существующую интеграцию с веб-сервисом, не забудь о том, что на вашей системе может быть логика, которую надо обновить. К примеру, вы считываете только определенные поля из ответа и надо добавить новые.

Левел 3. Самый важный проект за год, баги недопустимы!

Примеры ошибок. Возможно, потребуются сценарии и алерты на разные ошибки. Так ошибки описаны у Яндекс.Толоки

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

Синхронное / Асинхронное выполнение запроса. При Синхронном выполнении запроса, он обрабатывается сразу при получении. При асинхронном взаимодействии запросы попадают в очередь на стороне сервиса и целевое действие сразу не выполняется. У владельцев или пользователей сервиса можно узнать, сколько в среднем событие лежит в очереди и сколько еще требуется времени на обработку запроса. Успешные коды 201 и 202 намекают на асинхронность. Если ты их получил, лучше проверить, что целевое действие выполнится.

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

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

Рассмотрены в основном СКЗИ, использующиеся на клиентских местах для защиты клиент-серверных соединений по протоколу TLS, для организации ЭЦП, шифрования передаваемых данных;
Не рассматриваются СКЗИ, применяемые для создания VPN и шифрования файловой системы, хранимых данных, а так же УЦ;
Отдельно выделены аппаратные криптографические устройства.

технологий интеграции (CryptoAPI, Active-X, NPAPI и др.), которые поддерживают СКЗИ для встраивания в приложения и прикладные системы;
интерфейсов, которые предоставляют СКЗИ для встраивания в приложения и прикладные системы.

Криптопровайдеры

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

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

Отсутствие нормальной кроссплатформенности;
Установка с правами администратора, настройка;
Установка обновления Windows может потребовать обновления провайдера;
Необходимость встраивания в приложения посредством модификации кода «на лету»;
CSP — неродной интерфейс для не-Windows-приложений.

Широкий охват Windows-приложений;
Богатый инструментарий для разработчиков защищенных систем;
Апробированная на большом количестве проектов технология.

Нативные библиотеки

OpenSSL-style

Open Source библиотека OpenSSL обладает широкими криптографическими возможностями и удобным механизмом ее расширения другими криптоалгоритмами. OpenSSL является основным криптоядром для широкого спектра приложений Open Source.

После того, как в эту библиотеку компанией Криптоком были добавлены ГОСТы, появились патчи для «гостификации» многих популярных приложения, использующих OpenSSL. На базе OpenSSL некоторые вендоры разработали и сертифицировали СКЗИ, кроме того в ряд продуктов OpenSSL входит «неявным» образом.

OpenSSL и его аналоги не поддерживается приложениями Microsoft;
Необходимость патчить СПО, которое поддерживает OpenSSL, для включения ГОСТов.

Кроссплатформенность;
Использование в огромном количестве проектов, открытые исходники большей части проекта — выявление и устранение уязвимостей (как пример, недавнее выявление heartbleed);
Распространяется копированием — можно делать приложения, не требующие инсталляции;
Широкий охват приложений СПО, на базе которых можно делать защищенные сертифицированные продукты;
Широкая интеграция в фреймворки, но при этом проблемы с ГОСТами.

Функции доступа к устройству;
Функции записи/чтения произвольных данных;
Функции работы с ключами (поиск, создание, удаление, импорт, экспорт);
Функции работы с сертификатами (поиск, импорт, экспорт);
Функции ЭЦП;
Функции хэширования;
Функции шифрования;
Функции вычисления имитовставки;
Функции выработки ключа согласования (Диффи-Хeллман);
Функции экспорта/импорта сессионного ключа;

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

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

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

В данный момент существуют два проекта по «гостификации» NSS:

Библиотеки c собственным интерфейсом

Локальные прокси

Основным принципом действия локального прокси является прием незащищенного соединения от приложения, установка TLS-туннеля с удаленным сервером и передача «прикладного уровня» между приложением и удаленным сервером по этому туннелю.

прокси должен быть запущен;
приложение должно работать через прокси, нужно «научить» его этому;
могут использоваться нестандартные порты, отсюда проблемы в файрволом
если приложение «ходит» через localhost, то, например, в адресной строке браузера прописано localhost… — нестандартно
дополнительные ограничения на разработку web-сайта — в ряде случаев использование только относительных ссылок, чтобы не «вылететь» из туннеля
прокси сконфигурирован на проксирование конечной группы сайтов, расширение группы — это обновление клиентского конфига
работа через внешний прокси требует дополнительного конфигурирования локального прокси, при этом могут быть проблемы с аутентификацией пользователя на внешнем прокси

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

Браузерные плагины

Кроссбраузерные плагины

ActiveX

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

Содержание

Уровни интеграции данных

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

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

Возникающие задачи

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

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

Архитектуры систем интеграции

Консолидация

В случае консолидации данные извлекаются из источников, и помещаются в Хранилище данных. Процесс заполнения Хранилища состоит из трех фаз — извлечение, преобразование, загрузка (Extract, Transformation, Loading — ETL). Во многих случаях именно ETL понимают под термином «интеграция данных». Еще одна распространенная технология консолидации данных — управление содержанием корпорации (enterprise content management, сокр. ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.

Консолидация — однонаправленный процесс, то есть данные из нескольких источников сливаются в Хранилище, но не распространяются из него обратно в распределенную систему. Часто консолидированные данные служат основой для приложений бизнес-аналитики (Business Intelligence, BI), OLAP-приложений.

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

Федерализация

В федеративных БД физического перемещения данных не происходит: данные остаются у владельцев, доступ к ним осуществляется при необходимости (при выполнении запроса). Изначально федеративные БД предполагали создание в каждом из n узлов n-1 фрагментов кода, позволяющего обращаться к любому другому узлу. При этом федеративные БД отделяли от медиаторов [2] .

При использовании медиатора создается общее представление (модель) данных. Медиатор — посредник, поддерживающий единый пользовательский интерфейса на основе глобального представления данных, содержащихся в источниках, а также поддержку отображения между глобальным и локальным представлениями данных. Пользовательский запрос, сформулированный в терминах единого интерфейса, декомпозируется на множество подзапросов, адресованных к нужным локальным источникам данных. На основе результатов их обработки синтезируется полный ответ на запрос. Используются две разновидности архитектуры с посредником — Global as View и Local as View. [1]

Отображение данных из источника в общую модель выполняется при каждом запросе специальной оболочкой (wrapper). Для этого необходима интерпретация запроса к отдельным источникам и последующее отображение полученных данных в единую модель. Сейчас этот способ также относят к федеративным БД. [3]

Интеграция корпоративной информации (Enterprise information integration, сокр. EII) — это пример технологии, которая поддерживает федеративный подход к интеграции данных.

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

Распространение данных

Приложения распространения данных осуществляют копирование данных из одного места в другое. Эти приложения обычно работают в оперативном режиме и производят перемещение данных к местам назначения, то есть зависят от определенных событий. Обновления в первичной системе могут передаваться в конечную систему синхронно или асинхронно. Синхронная передача требует, чтобы обновления в обеих системах происходили во время одной и той же физической транзакции. Независимо от используемого типа синхронизации, метод распространения гарантирует доставку данных в систему назначения. Такая гарантия — это ключевой отличительный признак распространения данных. Большинство технологий синхронного распространения данных поддерживают двусторонний обмен данными между первичными и конечными системами. Примерами технологий, поддерживающих распространение данных, являются интеграция корпоративных приложений (Enterprise application integration, сокр. EAI) и тиражирование корпоративных данных (Еnterprise data replication, сокр. EDR). От фееративных БД этот способ отличает двустороннее распространение данных. [1]

Сервисный подход

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

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

Имея соответствующие учетные данные системы безопасности, потребитель может осуществить выборку любых данных из источника через почти неограниченное количество различных запросов SQL. Но для этого потребитель должен иметь представление о модели источника данных и способе создания результата с использованием этой базовой модели. Чем сложнее модель источника данных, тем более сложной может оказаться эта задача. [4]

Кроме того

В [1] описан пример гибридного подхода.

Другая классификация методов приведена в [5] .

Проблемы интеграции информации

Вне зависимости от выбранных технологии и метода интеграции данных, остаются вопросы, связанные с их смысловой интерпретацией и различиями в представлении одних и тех же вещей. Именно, приходится разрешать несоответствие схем данных [6] и несоответствие самих данных.

Типы несоответствия схем данных

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

Структурные и семантические конфликты выливаются в следующие проблемы:

Различие в типах данных. Некоторый домен в одном источнике может представляться числом, в другом — строкой фиксированной длины, в третьем — строкой переменной длины.
Различие в единицах измерения. В одной БД указана величина в сантиметрах, в другой — в дюймах. В этом случае существует отображение 1:1.
Различие в множестве допустимых значений. Один и тот же признак может определяться разными наборами констант. Например, выполнение задания одним источником может оцениваться по четырехбальной шкале(неудовлетворительно, удовлетворительно, хорошо, отлично), другим — по трехбальной (-,±,+), третьим — по стобальной. Отображение не является 1:1, оно может быть многозначным, может не иметь обратного, может зависеть от сторонних данных (например, 30 по математике соответствовать «удовлетворительно», а по русскому языку — «неудовлетворительно»).
Различие «домен-отношение». Домен в одной БД (напр строковое значение) соответствует таблице в другой БД (записи из таблицы-справочника).
Различие «домен — группа доменов». В одном источнике адрес записывается одной строкой, в другом — отдельные поля для улицы, дома, строения, квартиры.
Различие «данные-схема». Данные одной БД соответствуют схеме (метаданным) другой. В одной БД «инженер» — значение атрибута «должность» отношения «работник», в другой «инженеры» — отношение, содержащее некоторых работников, в то время как «бухгалтеры» содержит других.
Отсутствующие значения. В каком-то из источников может отсутствовать информация, имеющаяся в большинстве других.

Разрешение этих несоответствий часто выполняется вручную. Обзор автоматических методов разрешения несоответствия схем можно найти в [7] .

Типы несоответствия собственно данных

Перечисленные различия приводят к дублированию записей при интеграции данных в одну БД. Разрешение перечисленных проблем и устранение дублирования записей вручную практически невозможно. Имеется множество методов для ее автоматического и полуавтоматического решения. По-русски задача не имеет устоявшегося термина (применяются «сопоставление записей», «вероятностное соединение», «нестрогое соединение», «нестрогое соответствие»). В зарубежных работах эта задача носит название Identity resolution, или Record linkage (есть и другие синонимы). Обзор методов можно найти в [8] .

Читайте также: