Введение

Независимо от наличия или отсутствия корпоративных стандартов на предприятии разнообразие способов хранения и представления информации обусловлено рядом объективных обстоятельств, в частности, эволюционным характером развития информационной системы предприятия, например: табличный процессор -> персональная СУБД -> настольный (на 5-10 клиентов) БД-сервер -> полнофункциональный мощный сервер баз данных. При этом каждый следующий виток прогресса, как правило, не означает разрушение до основания старой системы во имя построения новой, какой бы производительной и масштабируемой она ни обещала быть. Перефразируя известное высказывание о душе математика, можно сказать, что за душу каждого программиста борются ангел бесконечного совершенства и дьявол здорового консерватизма. В любом случае внедрение новой технологии - процесс далеко не одномоментный, и в течение переходного периода необходимость максимально мирного сосуществования старых и новых форматов хранения в рамках одной информационной системы не вызывает сомнений. Более того, в подавляющем большинстве случаев унаследованные приложения не умирают бесследно, а продолжают тихо доживать свой век на каких-нибудь узкоспециализированных локальных задачах, данные из которых тем не менее должны быть доступны нашей комплексной современной и перспективной системе.

Другой вариант развития событий. Есть задача З₁, для которой покупается решение фирмы Ф₁ на платформе БД₁. Через некоторое время возникает задача З₂, которой фирма Ф₁ не занимается, но под которую есть решение у фирмы Ф₂, только вот беда - производится оно на БД₂ и ни на чем ином. Повздыхали, конечно, но делать нечего - купили. Так понемногу у нас на предприятии вместе с решениями собирается изрядный зоопарк СУБД. А спустя еще некоторое время появляется новая задача З₃, которой на входе требуются данные из БД₁, БД₂ и т.д., и вместо программирования бизнес-логики, разработчики вынуждены решать проблемы доступа к разнородным форматам данных.

Я думаю, приведенные примеры наверняка до боли знакомы большинству программистов, администраторов и IT-менеджеров. Разумеется, ими не исчерпываются все возможные сценарии, однако этого вполне достаточно для того, чтобы существование и актуальность проблемы интероперабельности различных систем управления данными считать доказанным. В сложившейся ситуации наиболее привлекательным и экономичным решением оказывается продукт, способный работать с данными любой природы независимо от их формата и места хранения. Этому требованию удовлетворяет Microsoft SQL Server 7.0, взаимодействующий как с собственным, так и с внешними механизмами хранения с помощью технологии универсального доступа OLE DB. Однако предметом нашего сегодняшнего разговора будет не сама технология OLE DB (предполагается, что слушателям она в той или иной степени известна), а ее реализация в Microsoft SQL Server 7.0 и открывающиеся в связи с этим возможности перед разработчиками гетерогенных серверных приложений.

Если отнести DTC-транзакции к тиражированию с максимально плотной (по протоколу двухфазной фиксации) целостностью, я бы выделил на стороне сервера три основных способа построения распределенных приложений - это тиражирование, службы преобразования данных (Data Transformation Services - DTS) и распределенные запросы. Все они логически связаны друг с другом: например, службы преобразования данных можно рассматривать как разновидность тиражирования мгновенных снимков данных (snapshots), а пакет DTS или шаг пакета может выступать в роли прилинкованного сервера. Каждый из них может в той или иной мере использоваться в реальных приложениях в процессе построения хранилищ данных при сборе и консолидации информации из внешних и распределенных OLTP-источников, однако наиболее яркая роль здесь безусловно принадлежит службам преобразования данных.

Содержание | Вперед