Автор: Сергей Кузнецов

Введение

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

Немного истории

Развитие информационных технологий, поддерживающих жизненный цикл корпоративных информационных систем, неразрывно связано с процессом развития аппаратуры и базового программного обеспечения компьютеров. В эпоху мейнфреймов в 60-70-е гг. XX века (ассоциируемую, прежде всего, с компанией IBM) по причине их исключительной дороговизны только очень крупные компании (например, крупные банки) могли позволить себе использование компьютеров для автоматизации своих бизнес-процессов. Ограниченный объем рынка не стимулировал должным образом развитие информационных технологий, способствующих массовому внедрению корпоративных информационных систем. Предлагаемые поставщиками проприетарные решения удовлетворяли потребности существующего рынка.

Набравшая силу в 80-е гг. линия миникомпьютеров (PDP-11 и VAX-11 компании Digital Equipment) несколько изменила ситуацию. Во-первых, стоимостные характеристики этих компьютеров сделали их доступными для гораздо большего числа компаний. Во-вторых, компания DEC разработала технологию DECnet, позволяющую комплексировать миникомпьютеры в локальную сеть, что, вообще говоря, давало возможность масштабирования корпоративных информационных систем. Однако в целом доступная технология оставалась проприетарной и все еще слишком дорогой для массового использования.

С середины 80-х гг. на рынке компьютеров и программного обеспечения началась эпоха OC UNIX (связанная, прежде всего, с деятельностью компании Sun Microsystems). Именно в мире UNIX возник стек сетевых протоколов TCP/IP, и именно поддержка этого стека в ОС UNIX позволила основателю компании Sun Биллу Джою произнести знаменитое Сеть это компьютер . Открытость интерфейсов ОС UNIX и наличие поддерживающих их стандартов дало жизнь направлению открытых систем, направленному на поддержку переносимых с одной платформы на другую и интероперабельных приложений. Принято считать, что именно в мире UNIX возникла идея клиент-серверных архитектур аппаратно-программных систем. UNIX-ориентированные компьютеры позволяли создавать масштабируемые корпоративные системы, не привязанные с какому-либо одному поставщику. Возможность разработки переносимых программных средств привела к резкому росту числа предложений на софтверном рынке. Однако, при наличии всех этих благоприятных обстоятельств, массовому распространению корпоративных систем препятствовала относительная дороговизна UNIX-рабочих станций, которые требовалось приобретать для оснащения рабочих мест информационной системы.

Примерно в те же годы компания IBM инициировала направление персональных компьютеров, навсегда зарезервировав за собой марку IBM PC. Исходной целью было создание рынка небольших, простых и дешевых массовых компьютеров, предназначенных, прежде всего, для решения офисных задач. Благодаря усилиям компаний Intel и Microsoft эти компьютеры непрерывно совершенствовались при постоянном снижении стоимости. Очень важным обстоятельством, привлекавшим к персональным компьютерам внимание компаний, которые нуждались в автоматизации некоторых видов своей деятельности (бухгалтерия, учет кадров, управление складом и т.д.), являлась простота организации аппаратуры и операционных систем. Это позволяло использовать разработчиков не слишком высокой квалификации для дешевого решения сиюминутных потребностей предприятия. Притом, что базовое программное обеспечение персональных компьютеров являлось полностью проприетарным, создаваемые таким образом приложения были также проприетарными и не масштабируемыми. Тем не менее, именно появление персональных компьютеров обеспечило возможность массовой автоматизации деятельности средних и даже мелких компаний.

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

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

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

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

Интеграция приложений

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

Реальные попытки создания инструментальных средств поддержки взаимодействия распределенных приложений начались после создания и первых реализаций стека протоколов TCP/IP и основывались на транспортных протоколах передачи сообщений TCP и UDP. Первым высокоуровневым механизмом взаимодействия приложений стал протокол и механизм удаленных вызовов процедур (Remote Procedure Call, RPC), созданный компанией Sun Microsystems в середине 80-х гг.

Идея состояла в том, что с использованием RPC в приложении могла быть объявлена процедура, к которой могли обращаться приложения, выполняющиеся на других компьютерах сети, так, как если бы это была обычная локальная процедура. На стороне сервера (приложения, реализующего удаленную процедуру) и клиента (приложения, использующего вызовы удаленной процедуры) процедура описывается с использованием языка IDL (Interface Definition Language язык определения интерфейсов). На основании IDL-описания автоматически строятся программные переходники-стабы (stub), являющиеся локальным представителем удаленной процедуры на стороне клиента и представителем вызывающего клиента на стороне сервера. Одной из функций клиентского стаба является преобразование аргументов вызова процедуры в машинно-независимую форму, а одной из функций серверного стаба преобразование полученных аргументов в машинное представление. Формат машинно-независимого представления аргументов регламентировался специально разработанным протоколом XDR (eXternal Data Representation внешнее представление данных). Реализации RPC положили начало развития нового вида программных продуктов middleware, программных средств промежуточного уровня, находящихся между приложением и операционной системой.

Следует заметить, что спецификации протокола RPC с самого начала были открытыми, что допускало реализацию RPC не только в среде ОС UNIX. Необходимость развития исходных спецификаций и согласования разных реализаций RPC привели к появлению в конце 80-х гг. консорциума OSF (Open Software Foundation), который занялся разработкой стандартов семейства DCE (Distributed Computing Environment), включавшего, помимо RPC, спецификации средств обеспечения безопасности, управления распределенными транзакциями, распределенных файловых систем и т.д. Для всех компонентов профиля DCE имелись доступные на рынке реализации, и их сертификация на предмет соответствия DCE гарантировала требуемую интероперабельность. В 1996 г. консорциум OSF объединился с консорциумом X/Open, отвечавшим за стандартизацию и сертификацию UNIX-систем, и был образован новый, существующий до сих пор консорциум OpenGroup (www.opengroup.org).

К концу 80-х гг. в компьютерном сообществе резко повысился интерес к объектным технологиям. Это относилось и к языкам программирования, и к базам данных, и к операционным системам, и к методологии проектирования программного обеспечения. Возникло ощущение, что объектно-ориентированный подход может качественно улучшить информационные технологии. Это ощущение распространялось и на средства построения распределенных систем и интеграции приложений. В 1989 г. по инициативе крупнейших компаний-производителей программного обеспечения был образован консорциум OMG (Object Management Group, www.omg.org), перед которым была поставлена задача выработки спецификаций промежуточного программного обеспечения, позволяющего создавать распределенные системы на основе объектно-ориентированного подхода. Подход получил название CORBA (Common Object Request Broker Architecture).

Если отвлечься от особенностей терминологии, подход CORBA являлся непосредственным развитием идей RPC. Снова с использованием языка IDL (объектного варианта, разработанного в OMG) можно было описать интерфейс объекта на стороне реализующего его приложения-сервера и на стороне использующих приложений-клиентов. В соответствии с этим описанием снова автоматически генерировались переходники-стабы, представляющие объект-сервер на стороне клиентских приложений и объекты-клиенты на стороне серверного приложения. За доставку аргументов вызываемому методу объекта и возвращение результатов вызова отвечал специальный компонент брокер объектных заявок, опирающийся на специальный транспортный протокол IIOP. Этот протокол строится на основе стека TCP/IP и отличается, например, от протокола HTTP тем, что в нем поддерживается сохранение состояния сессии взаимодействия объектов. При разработке спецификаций CORBA большое внимание уделялось возможности интеграции приложений, написанных на разных языках программирования. Для этого разрабатывались компиляторы языка IDL в соответствующие языки. В пакет спецификаций CORBA входили и спецификации так называемых объектных служб , которые должны были обеспечивать средства поддержки безопасности, транзакционности, постоянного хранения объектов и т.д.

Как и в случае DCE, все спецификации CORBA были (и являются) открытыми, и поддерживалось несколько их реализаций (например, реализации компаний BEA Systems и Iona Technologies). При наличии большого числа сторонников технология CORBA (как и технология RPC) не получила очень широкого распространения, главным образом по той причине, что для использования этой технологии требовались очень квалифицированные разработчики. Кроме того, для включения приложения в новую интегрированную среду требовалась модификация текста его исходных программ, что далеко не всегда возможно на практике. Еще одной особенностью технологии CORBA, ограничивающей, по моему мнению, ее распространение, была ее оторванность от Web-технологий, хотя было время, когда всерьез обсуждалась возможность замены протокола HTTP на IIOP. И еще замечу, что наряду с открытой брокерной технологией CORBA существовала (и существует) проприетарная технология от компании Microsoft DCOM, основанная на аналогичных принципах и обеспечивающая близкую функциональность. Имеются даже мосты и шлюзы между CORBA и DCOM.

В конце XX века громадное распространение Web-технологий и бурное развитие различных методов применения языка XML вывели компьютерное сообщество на новый виток спирали развития средств взаимодействия приложений. Консорциум W3C (World Wide Web Consortium, www.w3c.org) опубликовал спецификации механизма Web Services, который обеспечивает функциональность, близкую к функциональности CORBA, но полностью интегрируется с остальными Internet-технологиями и гораздо проще в использовании. Если не вдаваться в технические подробности, то технология Web-сервисов очень проста. Для определения интерфейса Web-сервиса на соответствующем Web-сервере используется язык WSDL (Web Service Definition Language). На сервере (обычно за счет инструментальных средств базового сервера приложений) определяется связь операций Web-сервиса с реализующими их приложениями. Каждому Web-сервису однозначно соответствует уникальный в Internet идентификатор ресурса (URI), неразрывно связанный с определением интерфейса Web-сервиса на WSDL. Для обращения к операции Web-сервиса с известными URI и интерфейсом клиент формирует сообщение с использованием протокола SOAP, определяющего способ представления аргументов вызова операций Web-сервиса на языке XML. Это сообщение посылается по указанному адресу с использованием протокола HTTP. Web-сервер разбирает сообщение, формирует реальные аргументы вызова и обращается к приложению. После получения результата вызова формируется ответное SOAP-сообщение и посылается клиенту.

Легко видеть, что с точки зрения общей технологии Internet-технология Web-сервисов является обобщением существовавших ранее частных возможностей, например, возможности формирования запроса от клиента к серверу с использованием заполнения форм. С другой стороны, понятно, что технология Web-сервисов, фактически, позволяет добиться всех результатов, обеспечиваемых технологией CORBA, оставаясь в рамках общей инфраструктуры Internet. Заметим, что при применении Web-сервисов для интеграции приложений, вообще говоря, не требуется доступ к исходным текстам приложений (в отличие от механизмов RPC и CORBA). Естественно, технология Web-сервисов поддерживается соответствующими средствами обеспечения безопасности и т.д.

Все спецификации Web-сервисов, разрабатываемые W3C и другими организациями (например, OASIS, www.oasis discount viagra.org), являются открытыми, и на рынке имеется много реализаций различных инструментальных средств. Однако в последнее время крупнейшие производители программного обеспечения предлагают интегрированные пакеты инструментальных средств категории middleware, основанные на концепции Web-сервиса и удовлетворяющие все возможные потребности (наиболее известны IBM WebSphere и Oracle Fusion Middleware).

Заметим, что появление технологии Web-сервисов активизировало еще одно направление интеграции корпоративных приложений, основанное на давно известной концепции потоков работ (workflow). Базовая идея состоит в том, что даже при наличии интегрированной корпоративной информационной системы крайне неразумно зашивать специфику бизнес-процессов предприятия в приложения. Тогда при появлении новых или отмирании существующих бизнес-процессов потребуется дорогостоящая переделка приложений. Подход потоков работ предполагает, что сценарии бизнес-процессов, определяющие порядок и правила взаимодействия приложений и работников предприятия в каждом бизнес-процессе, описываются на специальном языке и проигрываются специальной программной системой. Разработкой спецификаций стандартов, связанных с потоками работ, занимается несколько консорциумов, в том числе OMG, OASIS и WfMC (Workflow Management Coalition, www.wfmc.org). Для различных спецификаций (они всегда были открытыми) существовали реализации, но до сих пор они не получили широкого распространения.

В начале 2000-х гг. компании IBM, BEA Systems, Microsoft, SAP AG и Siebel Systems (последняя компания теперь принадлежит компании Oracle) разработали спецификацию языка BPEL4WS (Business Process Execution Language for Web Services, язык выполнения бизнес-процессов для Web-сервисов; более часто язык называют просто BPEL). Работа над развитием и стандартизацией BPEL продолжается в консорциуме OASIS, но ряд компаний (в частности, IBM и Oracle) уже предлагают его реализации. Интегрированность BPEL с технологиями XML и Web-сервисов, очевидно, будут способствовать более широкому распространению этой технологии.

Нельзя не упомянуть об альтернативном подходе к созданию интегрированных корпоративных информационных систем, основанных на решениях поставщиков технологии ERP (Enterprise Resource Planning, планирование ресурсов предприятия). Лидерами в этой области являются компании SAP с продуктом R3 и Microsoft с продуктом Axapta. Использование технологий ERP является вполне обоснованным при разработке корпоративной системы с нуля, потому что поставщики обеспечивают как инфраструктуру корпоративной системы, так и базовый набор модулей, на основе которых создаются приложения. Эти приложения интегрируются, главным образом, за счет использования общей корпоративной базы данных. Однако нельзя считать, что приобретение какого-либо ERP-решения немедленно приводит к появлению работоспособной корпоративной системы. Для этого необходимо выполнить относительно длительную и дорогостоящую процедуру внедрения, т.е. настройки под особенности предприятия, для чего обычно приходится привлекать внешних квалифицированных специалистов.

Интеграция данных

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

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

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

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

Частные решения задачи интеграции данных предлагали поставщики реляционных СУБД. Например, в СУБД IBM DB2 поддерживался (и до сих пор поддерживается) шлюз для доступа к иерархическим базам данных, управляемым СУБД IMS, в СУБД INGRES компании Computer Associates обеспечивался доступ к сетевым базам данных, управляемым СУБД IDMS и т.д. Более того, большинство поставщиков развитых реляционных СУБД (IBM, Oracle, Informix, Sybase и т.д.) поддерживало в своих продуктах шлюзы для доступа к базам данных, управляемых СУБД других поставщиков. Эти решения, конечно, были полезны, но в общем случае не позволяли справиться с проблемой интеграции данных в корпоративной системе.

Очень сильное воздействие на организацию корпоративных информационных систем с несколькими базами данных оказала разработка компанией Microsoft интерфейса ODBC (Open DataBase Connectivity) и появление соответствующей спецификации CLI (Call Level Interface, интерфейс уровня вызовов) в стандарте языка SQL. Стандартизация библиотеки функций и подмножества языка SQL, обеспечивающих возможность обращаться к любой базе данных, для которой поддерживается соответствующий ODBC-драйвер, сильно снизило остроту проблемы интеграции данных. Практически все поставщики коммерческих и свободно доступных СУБД обеспечили ODBC-драйвера для доступа к своим базам данных, а открытость стандарта позволила создавать такие драйверы сторонним разработчикам. Конечно, ODBC (и появившийся позже интерфейс JDBC Java DataBase Connectivity) обеспечивает не интеграцию данных, а всего лишь доступ из приложения к различным базам данных, но, во-первых, часто это оказывается достаточным, и, во-вторых, ограниченность технологии окупается ее простотой и эффективностью.

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

Хранилища данных, оперативная аналитическая обработка данных

Принято выделять два основных вида приложений, работающих с базами данных: приложения оперативной обработки транзакций (OLTP-приложения, OnLine Transaction Processing) и приложения оперативной аналитической обработки (OLAP-приложения, OnLine Analytical Processing). Простым примером OLTP-приложения является приложение управления складом с операциями «принять на склад», «отпустить со склада» и т.д. OLTP-приложения интенсивно выполняют короткие транзакции, обычно состоящие из очень простых операций, изменяющих состояние базы данных. В соответствующей базе данных обычно оказывается достаточным сохранять только текущие данные, характеризующие состояние управляемого объекта. Примером OLAP-приложения может служить система, поддерживающая составление бухгалтерских отчетов. Такому приложению обычно требуются сводные статистические данные, например, средняя зарплата некоторой категории служащих за определенное время. OLAP-приложения обычно не обновляют базу данных, и эта база данных должна сохранять в основном агрегированные данные за достаточно долгий период времени.

Более того, если для многих OLTP-приложений требуется только небольшая часть текущих корпоративных данных (складскому приложению данные о складе, бухгалтерскому приложению бухгалтерские данные и т.д.), то OLAP-приложению могут потребоваться общекорпоративные сводные (а может быть, и детальные данные), а также внешние данные, характеризующие, например, деятельность конкурирующих и/или партнерских предприятий. Это особенно проявляется в OLAP-приложениях, направленных на поддержку принятия решений корпоративными менеджерами высшего звена. Для поддержки таких приложений невозможно обойтись виртуальной интеграцией корпоративных баз данных, на которых основываются OLTP-приложения: в этих базах данных не сохраняется информация, которая была актуальна в прошлом, и внешняя информация (все это просто не требуется для OLTP-приложений). Все эти рассуждения приводят нас к потребности предприятия, нуждающегося в поддержке OLAP-приложений, в физически отдельной, потенциально громадной базе данных, хранящей агрегированные исторические данные о деятельности предприятия и внешнем мире. Такую базу данных называют хранилищем данных (неудачный, но принятый в русскоязычной литературе перевод американского термина data warehouse).

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

В качестве технических средств построения хранилища данных обычно используется некоторая реляционная СУБД, способная поддерживать очень большие базы данных и эффективно выполнять над ними произвольно сложные запросы. Таким требованиям удовлетворяют, например, СУБД DB2 компании IBM, Teradata компании NCR, Oracle, отчасти Microsoft SQL Server. Нужно понимать, что для поддержки сверхбольших баз данных должны использоваться соответствующие мощные аппаратные средства. Для целей аналитической обработки вокруг центрального хранилища данных часто организуются меньшие по объему тематически ориентированные части хранилища данных, называемые витринами данных (data mart; русский вариант термина неудачен, но уже принят). Для технической поддержки витрин данных можно эффективно использовать специализированные многомерные СУБД (например, Oracle Express Server или OLAP Server компании SAS Institute).

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

Для заполнения хранилища данных применяется процедура ETL (Extraction, Transformation, Loading – извлечение, преобразование, загрузка). Эта процедура обычно выполняется периодически (например, раз в день) и в соответствии с названием сводится к тому, что из источников данных извлекаются новые данные. Эти данные подвергаются трансформации в соответствии с форматами хранения, принятыми в хранилище данных; наконец, данные в преобразованной форме загружаются в хранилище данных (во время загрузки производится и требуемая агрегация данных). Основной сложностью процедуры ETL является то, что в разных источниках могут находиться эквивалентные по смыслу, но различающиеся по значениям данные. Нужно каким-то образом распознать факт наличия подобного противоречия и выбрать данные, которые по некоторым критериям являются более достоверными. Эта задача не является формализованной (и, скорее всего, не может быть формализована в общем случае), и поэтому выполнение процедуры ETL обычно является полуавтоматическим с участием эксперта-специалиста в предметной области предприятия.

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

Естественно, к методологическим аспектам построения хранилища данных относится и проблема разработки или внедрения требуемых OLAP-приложений. Имеется множество независимых поставщиков как готовых подобных приложений (я ставлю кавычки, поскольку любое такое приложение нужно внедрить, т.е. приспособить к особенностям предприятия), так и средств их разработки. Более того, крупные поставщики BI-решений (например, Oracle и SAS Institute) готовы полностью поддерживать весь проект создания хранилища данных за счет предоставления своих продуктов. Возможно, применение такого подхода несколько снизит трудности выполнения соответствующего проекта (за счет, например, поддержки всех фаз проекта одним поставщиком) и сократит сроки его выполнения, но я почти уверен, что проект не станет дешевле.

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

Заключение

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

Источник: http://www.k-press.ru