Раздел 21. Программное обеспечение распределенных систем и сетей

125. Средства и методологии проектирования, разработки и сопровождения файл-серверных приложений: традиционные средства и методологии разработки файл-серверных приложений, новые средства разработки файл-серверных приложений, перенос файл-серверных приложений в среду клиент-сервер.

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

3.1. Традиционные средства и методологии разработки файл-серверных приложений

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

3.1.1. Системы программирования и библиотеки

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

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

Отметим основные вехи на пути развития систем программирования:

• Переход от одиночных утилит систем программирования к интегрированным диалоговым средам программирования (например, семейство Turbo-продуктов фирмы Borland);

• Развитие инструментальных наборов, расширяющих возможности систем программирования, в частности, в области диалога (разного рода Tool Box);

• Появление объектно-ориентированных диалектов языков Си и Паскаль; заметим, что по нашему мнению, несмотря на то, что Паскаль является более строгим и корректным языком, феномен Си++ имеет большее значение в силу наличия стандарта;

• Возникновение операционной среды Windows со встроенной поддержкой диалога и первых Windows-приложений с помощью SDK (Software Development Keet);

• Создание объектно-ориентированных библиотек, поддерживающих диалоговый режим работы в среде DOS и Windows (TurboVision, Object Windows и MFC);

• Появление систем программирования, облегчающих создание приложений для DOS и Windows;

• Развитие механизма встраивания и связывания объектов OLE 2;

• Переход к визуальным системам программирования (Visual Си++, Delphi, Visual Basic), которые ориентированы на разработку информационных приложений.

Поддержка диалогового режима развивалась совместно с развитием самих систем программирования и была естественным образом интегрирована с ними. Библиотеки же доступа к базам данных развивались своим путем. Наибольшее число библиотек доступа из языков программирования уровня 3GL к реляционным СУБД на персональных компьютерах поддерживает семейство xBase (Clipper, FoxPro, dBase). Из языков программирования чаще всего используется Си. Также можно отметить наличие таких библиотек, как CodeBase и DBTools (фирма Rogue Wave).

В библиотеке CodeBase используются те же форматы данных, индексов и memo-файлов, что и в СУБД dBase IV. Имеется возможность поддержки индексных файлов Clipper и memo-файлов dBase III Plus. Имеющиеся в библиотеке CodeBase функции могут не только выполнять все стандартные операции СУБД семейства xBase, но и позволяют устанавливать фильтры, задавать отношения, вычислять допустимые в СУБД выражения. Библиотечные функции поддерживают многопользовательские режимы работы в локальной сети и в среде многозадачной ОС, обеспечивая блокировку как на уровне файлов, так и записей. В комплект поставки входят тексты функций, что позволяет адаптировать их для конкретного использования.

Библиотека DBTools является многоплатформенной библиотекой для языков Си/Си++ и рассчитана на поддержку семейства СУБД xBase, Informix, Oracle и др.

3.1.2. Средства и методы разработки приложений на основе СУБД на персональных компьютерах

Приложения, созданные с использованием инструментальных средств программирования приложений, связанных с использованием баз данных на персональных компьютерах, занимают существенную долю файл-серверных приложений. Если рассматривать только "реляционные" (вернее, табличные) СУБД, то семейство xBase-продуктов является явным лидером по использованию для разработки одиночных и групповых информационных приложений. Следующее место занимает СУБД Paradox, а далее идут приложения, базирующиеся на использовании системы управления записями Clarion. Особняком стоят такие пакеты, как MS Access и Lotus Approach, которые позволили взглянуть по-новому на возможности персональных СУБД и до сих пор не оценены по-настоящему как профессиональные средства разработки приложений. Можно отметить следующие вехи на пути развития инструментальных средств и самих СУБД на персональных компьютерах:

• Появление компонентов Assistant и Application Generator в dBase III Plus, упрощающих работу пользователя и позволяющих генерировать простейшие приложения или макеты приложений;

• Выход в свет dBase-совместимых систем программирования (dBFast и Clipper), создающих исполняемый модуль приложения; разработка быстрого интерпретатора FoxBase для частично откомпилированного кода dBase-совместимых приложений;

• Возникновение системы Paradox с оригинальным макроязыком PAL, существенно ориентированной на конечного пользователя;

• Развитие многопользовательских версий СУБД для локальных сетей персональных компьютеров, дополненных средствами синхронизации на основе блокировок файлов и записей;

• Появление системы dBase IV, включающую диалоговую среду Control Center, индексы, встроенные в файл БД, поддержку языка SQL и средства защиты БД;

• Развитие Clipper с объектной ориентацией;

• Обеспечение доступа из файл-серверных приложений к серверам БД (Borland SQL Link и Microsoft Connectivity Kit);

• Внедрение технологии Rushmore, ускоряющей доступ к данным при помощи использования индексов;

• Появление в FoxPro развитой среды разработки, ориентированной на разработку проектов и близкой по возможностям к средствам 4GL;

• Дальнейшее расширение средств диалога (Foundation Read) в направление событийной управляемости;

• Первые версии инструментальных средств, поддерживающие Windows-приложения, а вместе с ними типы данных Blob (Binary Large Objects);

• Появление универсальных интерфейсов к различным СУБД (Borland IDAPI и Microsoft ODBC);

• Первый продукт MS Access, направленный сугубо на создание Windows-приложений и содержащий средства объектно-ориентированного диалога, событийно-управляемого программирования, визуального конструирования интерфейса пользователя и многие другие черты, присущие системам программирования 4GL и RAD;

• Появление новых визуальных объектно-ориентированных инструментальных средств и СУБД на ПК (MS Access 2.0, Visual FoxPro, CA-VisualObjects и Visual dBase).

3.2. Новые средства разработки файл-серверных приложений

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

3.2.1. Общая характеристика современных средств

В индустрии СУБД для персональных компьютеров отразились тенденции нормализации систем (Rightsizing). В последнее время в этой области происходили два встречных процесса: (1) разукрупнение серверов БД - появление новых версий серверов БД Informix, Oracle и т.д. сначала в варианте для рабочих групп, а потом облегченные версии для одиночных персональных компьютеров; (2) укрупнение СУБД для персональных компьютеров - новые "персональные" СУБД и связанные с ними инструментальные средства развивались в сторону "истинно реляционных" СУБД, т.е. серверов БД, приложений клиент-сервер и инструментальных средств программирования 4GL и быстрой разработки RAD.

Новые СУБД для персональных компьютеров и соответствующие инструментальные средства разработки файл-серверных приложений обладают перечисленными ниже общими чертами.

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

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

• Встроенная поддержка языка структурированных запросов SQL (Standard Query Language) закладывает возможность масштабирования создаваемых файл-серверных приложений до уровня приложений клиент-сервер.

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

• Использование объектно-ориентированного языка разработки приложений (по крайней мере в части диалога) позволяет широко использовать механизм наследования и тем самым использовать ранее произведенные программные компоненты.

• Поддержка компонентно-ориентированного программирования дает возможность расширения приложений за счет использования готовых внешних визуальных объектов типа VBX и OCX (ActiveX).

• "Истинно реляционная" база данных представляет собой объединенный набор файлов, содержащий таблицы, индексы и т.п., что облегчает сопровождение БД и приложений и является основой для поддержки целостности данных.

• Поддерживается общий для информационной системы словарь данных (data dictionary), который содержит описание структуры БД, типы полей, правила поддержки ограничений целостности и т.п.

• Поддержка целостности БД (данных, ссылок и транзакций) позволяет создавать приложения с необходимым уровнем надежности и сохранности данных.

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

• Хранение в БД описания проекта создаваемого приложения является прообразом репозитория инструментальных средств быстрой разработки RAD и CASE-систем.

Рассмотрим подробнее несколько примеров сравнительно новых инструментальных средств: MS Access 2.0, Visual FoxPro и CA-VisualObjects.

3.3. Перенос файл-серверных приложений в среду клиент-сервер

Усложнение информационных приложений, их интеграция в корпоративные сети, создание распределенных БД коллективного пользования требуют новых инструментальных средств и "истинно реляционных" СУБД. Традиционно используемые "персональные" СУБД типа Clipper и FoxPro не могут обеспечить требуемый уровень надежности и достоверности информации, особенно при работе в сетях. Подобные СУБД не поддерживают целостность баз данных и не имеют механизмов управления транзакциями, что существенно затрудняет обеспечение логической непротиворечивости информации при сбоях оборудования и программ.

Возросшим требованиям удовлетворяет архитектура клиент-сервер, основанная на выделении одного узла сети под сервер БД с реляционной СУБД, поддерживающей максимальный уровень надежности хранения, ее актуальность и достоверность. До недавнего времени создание приложений для таких СУБД было делом непростым и требовало высокой квалификации, методика программирования на непроцедурном языке SQL не согласуется с опытом разработки приложений для СУБД на персональных компьютерах.

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

Существует несколько подходов к интеграции и адаптации файл-серверных приложений к архитектуре клиент-сервер:

• использование библиотек доступа к серверам БД;

• связь с сервером БД через открытый протокол ODBC;

• укрупнение файл-серверных приложений.

Чтобы оценить возможности этих способов, рассмотрим их несколько подробнее.

3.3.1. Библиотеки доступа к базам данных

Библиотеки доступа к серверам приложений удобно применять для адаптации файл-серверных приложений, построенных на системах программирования типа Clipper или Clarion.

Система управления записями Clarion достаточно легко связывается с сервером баз данных Btrieve через библиотеку доступа. Нужно только заметить, что Btrieve не является SQL-сервером БД, что затрудняет программирование с использованием этого средства.

Приложения, построенные на Clipper, можно адаптировать с помощью программного интерфейса с выбранным сервером БД. Для примера рассмотрим библиотеку интерфейса Clipper-Oracle.

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

С помощью функций этой библиотеки можно выполнять следующие операции над таблицами базы данных системы Oracle:

• подключиться к системе Oracle;

• вставить в базу данных новую строку;

• удалить существующую строку;

• произвести модификацию содержимого полей существующей строки;

• выполнить поиск строк по заданному точному значению полей;

• выполнить поиск строк по заданному шаблону значений полей;

• выполнить поиск строк по их относительному номеру в заданной группе;

• блокировать и разблокировать таблицы;

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

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

Кроме того, существует возможность прямого использования языка SQL, который является основным языком обработки данных не только в системе Oracle, но и в большинстве других развитых СУБД.

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

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

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

В состав библиотеки входят следующие функции:

INIT () подключение к Oracle;

OPEN () открытие таблицы;

INSERT () добавление строки;

UPDATE () корректировка строки;

DELETE () удаление строки;

SELECT () поиск строки;

NEXT () чтение следующей строки;

SET () чтение строки по относительному номеру;

SKIP () пропуск строк;

FILTER () выбор строк по условию;

GETIND () сохранение индекса;

SETIND () установка индекса;

COMMIT () конец транзакции;

SAVE () установка контрольной точки;

ROLL () откат транзакции;

LOCK () блокировка таблицы;

SQL () выполнение оператора SQL;

CLOSE () закрытие таблицы;

STOP () отключение от Oracle.

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

В состав интерфейсных средств включен специальный модуль для автономной отладки прикладных программ без системы Oracle. Этот модуль выполняет все функции интерфейса на DBF-файлах, что позволяет разрабатывать и полностью отлаживать программы, используя только систему Clipper на обычном персональном компьютере. Кроме того, эта возможность позволяет разрабатывать прикладные программы сразу в двух вариантах - сетевом и автономном.

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

3.3.2. Протокол ODBC и его реализации

Интерфейс прикладного программирования ODBC API предоставляет общие методы доступа на основе языка баз данных SQL как к реляционным, так и к нереляционным (ISAM) источникам данных.

Наиболее современный стандарт ANSI SQL (фактически, это часть разрабатываемого стандарта SQL-3) включает спецификацию интерфейса на уровне вызовов (CLI - Call-Level Interface), на которую опирается ODBC для обеспечения доступа и работы с данными во многих системах управления базами данных. Интерфейс CLI соответствует требованиям, установленным в 1996 году комитетом SQL Access Group и определяющим общий синтаксис SQL и интерфейса API. Иметь общий метод доступа к источникам данных удобно потому, что тогда база данных на сервере становится прозрачной для приложений, которые написаны в соответствии со специфицированным уровнем совместимости ODBC.

Интерфейс ODBC API реализован как набор расслоенных DLL-функций для Windows. Динамическая библиотека ODBC.DLL - это основная библиотека управления драйверами ODBC, которая содержит функции вызовов специализированных драйверов для разных поддерживаемых системой баз данных. Каждый драйвер совместим со своим уровнем CLI и относится к одной из двух категорий: одноуровневые или многоуровневые драйверы.

Одноуровневые драйверы предназначены для использования при работе с теми источниками данных, которые не могут быть прямо обработаны с использованием ANSI SQL. Обычно это локальные базы данных на персональных компьютерах, такие как dBase, Paradox, FoxPro и Excel. Драйверы, соответствующие этим базам данных, производят компиляцию ANSI SQL в наборы инструкций более низкого уровня, которые непосредственно обрабатывают составляющие базу данных файлы.

Многоуровневые драйверы используют сервер РСУБД для обработки SQL-предложений и предназначены для работы в среде клиент-сервер. Помимо обработки ANSI SQL, они также могут поддерживать и собственные конструкции конкретной РСУБД, поскольку ODBC может без трансляции передавать SQL-операторы источникам данных (механизм "passthrough"). Драйверы ODBC для баз данных, поддерживаемым в технологии клиент-сервер реализованы для Oracle V 6.0 и Oracle V 7, а также Informix, Microsoft и Sybase SQL Server, Rdb, DB2, Ingres, HP/Image и An SQL. Драйверы можно приобрести в фирмах Microsoft, Intersolv, Visigenic и Openlink, причем только Microsoft и Intersolv выпускают и 32-х, и 16-ти разрядные драйверы.

Существует 4 важных этапа (шага) процедуры запроса данных через ODBC API.

• Шаг 1 - установление соединения. Первый шаг состоит в размещении указателей (handle) среды ODBC, которые выделяют оперативную память под ODBC драйверы и библиотеки. Затем происходит выделение памяти для указателей соединения, и соединение устанавливается.

• Шаг 2 - выполнение оператора SQL. Выделяется указатель оператора, локальные переменные связываются со столбцами в SQL-выражении (это необязательное действие), и выражение представляется главному ODBC-драйверу для обработки.

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

• Шаг 4 - освобождение ресурсов. После того, как данные получены, ресурсы освобождаются путем вызова функций освобождения указателей оператора, соединения и среды. Указатели оператора и соединения могут быть использованы в процессе обработки.

Технология ODBC разрабатывалась как общий, независимый от источников данных, способ доступа к данным. Применение технологии должно было также обеспечить переносимость приложений в среду различных баз данных без потребности переработки самих приложений. В этом смысле технология ODBC уже стала промышленным стандартом, ее поддерживают практически все производители СУБД и средств разработки.

Однако универсальность стоит дорого. Если при разработке приложений одним из основных критериев является переносимость на различные СУБД, то использование ODBC является оправданным. Для увеличения производительности и эффективности приложения активно применяют специфические для данной СУБД расширения языка SQL, используют хранимые на сервере процедуры и функции. В этом случае теряется роль ODBC как общего метода доступа к данным. Тем более, что для разных СУБД драйверы ODBC поддерживают разные уровни совместимости. Поэтому многие производители средств разработки, помимо поддержки ODBC, поставляют "прямые" драйверы к основным СУБД.

3.3.3. Укрупнение приложений (Upsigsing)

Пакет Microsoft Access Upsizing Tools позволяет автоматизировать процесс перехода от настольных баз данных к архитектуре клиент-сервер, в данном случае - от Microsoft Access к Microsoft SQL Server для Windows NT. Данный продукт добавляет к Access такие модули, как Upsizing Wizard и SQL Server Browser. Upsizing Wizard позволяет задать все параметры процесса переноса данных с помощью серии диалогов, а затем создает саму базу данных, журнал транзакций, таблицы, индексы, правила проверок значений данных, отношения между таблицами и поля типа timestamp (временная метка). Browser позволяет управлять объектами Access Server с помощью Access-подобного интерфейса. В комплект поставки также входит дискета с ODBC 2.0 и ODBC-драйвером для Microsoft SQL Server. База данных Access (файл с расширением .MDB) содержит таблицы данных и индексы, а также компоненты управления данными (запросы, макросы, модули, формы и отчеты).

Применение Microsoft Access Upsizing Tools основывается на концепции прозрачного для пользователя размещения данных: перенос информации в базу данных SQL Server при сохранении в исходном виде остальной части Access MDB. Access способен работать в качестве клиента в архитектуре клиент-сервер, поэтому разработчикам, переносящим приложения с помощью этого инструмента, не нужно отказываться от Access. Запросы, отчеты и прочие объекты остаются в неизменном виде, так как Upsizing Wizard перенаправляет их на экспортированные таблицы, переименовывая при этом локальные таблицы.

Upsizing Wizard учитывает при переносе ряд архитектурных различий между Microsoft Access и SQL Server для Windows NT. Он экспортирует таблицы и их свойства, такие как правила проверок, значения по умолчанию и индексы. Он выполняет такие операции, как добавление поля типа timestamp, преобразование отношений между таблицами Access в триггеры, поддерживающие ссылочную целостность, и даже создание INSERT-триггеров для аналогов автоинкрементируемых полей Access типа Counter. Upsizing Wizard не экспортирует из базы данных Access сведения о пользователях, группах и правах доступа, поэтому администратор базы данных должен устанавливать права доступа вручную. Upsizing Wizard создает подробный отчет, содержащий имена баз данных и размеры, параметры переноса, триггеры, таблицы (старые и новые), а также информацию об ошибках, возникших в процессе работы.

Модули Microsoft Wizard - это инструменты для автоматизации операций, направляющие действия пользователя в нужной последовательности. Access Upsizing Wizard не является примитивным продуктом, так как пользователю может понадобиться вручную конфигурировать систему для обеспечения нормальной работы, но, несмотря на это, покупка Microsoft Access Upsizing Tools будет оправдана для тех, кому необходимо перемещать данные из Access в SQL Server. Эта программа автоматизирует большинство рутинных моментов процесса, которые могут оказаться утомительными и нетривиальными, а документация включает специальный раздел по оптимизации использования Microsoft Access в качестве клиента в приложениях типа клиент-сервер.

126. Средства и методологии проектирования, разработки и сопровождения клиент-серверных приложений: базовые средства построения ИС в архитектуре «клиент-сервер», серверы баз данных, язык SQL – базовый интерфейс SQL-сервера, классический подход к проектированию реляционных баз данных, CASE-системы для проектирования ИС.

* Базовые средства построения ИС в архитектуре "клиент-сервер"

Архитектура "клиент-сервер обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к БД в локальной сети. Реальное распространение архитектуры "клиент-сервер" стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем. Основным смыслом подхода открытых систем является упрощение комплексирования вычислительных систем за счет международной и национальной стандартизации аппаратных и программных интерфейсов. Главной побудительной причиной развития концепции открытых систем явились повсеместный переход к использованию локальных компьютерных сетей и необходимость решения проблем комплексирования аппаратно-программных средств, которые вызвал этот переход. Ключевой фразой открытых систем, направленной в сторону пользователей, является независимость от конкретного поставщика. Ориентируясь на продукцию компаний, придерживающихся стандартов открытых систем, потребитель, который приобретает любой продукт такой компании, не попадает к ней в рабство. Он может продолжить наращивание мощности своей системы путем приобретения продуктов любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных, так и программных средств и не является необоснованной декларацией. Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту переноса программной системы в широком спектре аппаратно-программных средств, соответствующих стандартам. Интероперабельность означает возможность упрощения комплексирования новых программных систем на основе использования готовых компонентов со стандартными интерфейсами.

Вызовы удаленных процедур

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста. При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования. Основными идеями механизма вызова удаленных процедур (RPC - Remote Procedure Call), который представляет собой технологическую основу архитектуры "клиент-сервер", являются следующие:

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

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

Протокол RPC и его реализации

Впервые пакет RPC был реализован компанией Sun Microsystems в 1984 г. в рамках ее продукта NFS (Network File System - сетевая файловая система). Пакет был тщательно специфицирован с тем, чтобы пользовательский интерфейс и его функции не были зависимыми от применяемого транспортного механизма.

Протокол XDR. Независимость от конкретного машинного представления данных обеспечивается отдельно специфицированным протоколом XDR (External Data Representation - внешнее представление данных). Этот протокол определяет стандартный способ представления данных, скрывающий такие машинно-зависимые свойства как порядок байтов в слове, требования к выравниванию начального адреса структуры, представление стандартных типов данных и т.д. По существу, XDR реализуется как независимый пакет, который используется не только в RPC, но и в других продуктах (например, в NFS).

Стек протоколов TCP/IP как основа RPC. TCP/IP (Transmission Control Protocol/Internet Protocol) представляет собой семейство протоколов, основным назначением которых является обеспечение возможности полезного сосуществования компьютерных сетей, основанных на разных технологиях. Для разрешения проблемы различий в форматах кадров, используемых в разных сетях, был определен универсальный формат пакета данных, называемого IP-дейтаграммой (Internet Protocol Datagram), состоящего из заголовка и порции данных и поэтому похожего на обычный сетевой кадр. Однако порция данных IP-дейтаграммы сама содержится внутри сетевого кадра, т.е. IP-дейтаграмма погружается в сетевой кадр конкретного формата и поэтому может передаваться в разных сетях, входящих в Internet. Все узлы, шлюзы и сети Internet должны быть в состоянии понимать IP-дейтаграммы. Протокол TCP (Transmission Control Protocol) обеспечивает надежную доставку сообщений за счет подтверждений доставки дейтаграмм и их повторной передачи в случае надобности. Если узел, посылающий дейтаграмму, не получает подтверждение о ее доставке в течение установленного промежутка времени, то считается, что дейтаграмма не доставлена, и она посылается повторно. Полное семейство протоколов, основанных на использовании IP-дейтаграмм, называется TCP/IP. Наиболее важными и базисными протоколами этого семейства (или стека, как его часто называют) являются кратко описанные выше протоколы IP и TCP.

Семейство протоколов TCP/IP

- TCP - Протокол управления передачей (Transmission Control Protocol)

- UDP - Протокол пользовательских дейтаграмм (User Datagram Protocol)

- ARP - Протокол разрешения адресов (Address Resolution Protocol)

- RARP - Протокол обратного разрешения адресов (Reverse Address Resolution Protocol)

- IP - Протокол Internet (Internet Protocol)

- ICMP - Протокол управляющих сообщений Internet (Internet Control Message Protocol)

- FTP - Протокол пересылки файлов (File Transfer Protocol)

- TFTP - Простой протокол пересылки файлов (Trivial File Transfer Protocol)

В наиболее стандартной на сегодняшний день реализации UNIX System V Release 4 протокол TCP/IP реализован как набор специализированных потоковых модулей плюс дополнительный компонент TLI (Transport Level Interface - Интерфейс транспортного уровня). TLI является интерфейсом между прикладной программой и транспортным механизмом. Приложение, пользующееся интерфейсом TLI, получает возможность использовать TCP/IP. Интерфейс TLI основан на использовании классической семиуровневой модели ISO/OSI, которая разделяет сетевые функции на 7 областей, или уровней. Цель модели в обеспечении стандарта сетевой связи компьютеров независимо от производителя аппаратуры компьютеров и/или сети. 7 уровней модели можно кратко описать следующим образом:

1: Физический уровень (Physical Level) - среда передачи (например, Ethernet). Уровень отвечает за передачу неструктурированных данных по сети.

2: Канальный уровень (Data Link Layer) - уровень драйвера устройства, называемый также уровнем ARP/RARP в TCP/IP. Этот уровень, в частности, отвечает за преобразование данных при исправлении ошибок, происходящих на физическом уровне.

3: Сетевой уровень (Network Level) - отвечает за выполнение промежуточных сетевых функций, таких как поиск коммуникационного маршрута при отсутствии возможности прямой связи между узлом-отправителем и узлом-получателем. В TCP/IP этот уровень соответствует протоколам IP и ICMP.

4: Транспортный уровень (Transport Level) - уровень протоколов TCP/IP или UDP/IP семейства протоколов TCP/IP. Уровень отвечает за разборку сообщения на фрагменты (пакеты) при передаче и за сборку полного сообщения из пакетов при приеме таким образом, что на более старших уровнях модели эти процедуры вообще незаметны. Кроме того, на этом уровне выполняется посылка и обработка подтверждений и, при необходимости, повторная передача.

5: Уровень сессий (Session Layer) - отвечает за управление переговорами взаимодействующих транспортных уровней. В NFS этот уровень используется для реализации механизма вызовов удаленных процедур.

6: Уровень представлений (Presentation Layer) - отвечает за управление представлением информации. В NFS на этом уровне реализуется механизм внешнего представления данных (XDR - External Data Representation), машинно-независимого представления, понятного для всех компьютеров, входящих в сеть.

7: Уровень приложений - интерфейс с такими сетевыми приложениями как telnet, rlogin, mail и т.д.

Интерфейс TLI соответствует трем старшим уровням этой модели (с пятого по седьмой) и позволяет прикладному процессу пользоваться сервисами сети без необходимости знать о деталях транспортного и более низких уровней. Развитие идей RPC (пакет ONC+ компании Sun Microsystems)

В классическом протоколе (и его реализациях) RPC присутствует один недостаток, присущий процедурным методам взаимодействия вообще. Этот недостаток состоит в поддержании исключительно синхронного способа взаимодействия с удаленной процедурой. Другими словами, хотя процесс-клиент является независимым и мог бы произвести полезные действия на фоне выполнения удаленной процедуры, он не может этого сделать в силу ограниченности протокола. Соответствующие расширения появились в пакете ONC+ компании Sun Microsystems. Основная идея расширений состоит в том, что нецелесообразно обязательно заставлять клиента ожидать поступления результатов удаленной процедуры до тех пор, пока они ему действительно не понадобятся. Вызов удаленной процедуры становится асинхронным с синхронизацией в точке получения результатов. Заметим, что хотя асинхронный вызов удаленных процедур потенциально обеспечивает большую эффективность взаимодействия клиента и сервера, эта возможность усложняет программирование, заставляя явно использовать средства синхронизации независимых процессов. Следует сделать еще одно замечание, состоящее в том, что аналогичный механизм асинхронного вызова удаленных процедур используется в протоколе межброкерных взаимодействий CORBA-2.

* Серверы БД как базовая системная поддержка информационной системы в архитектуре "клиент-сервер"

Термин "сервер БД" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к БД. Хотя обычно одна БД целиком хранится в одном узле сети и поддерживается одним сервером, серверы БД представляют собой простое и дешевое приближение к распределенным БД, поскольку общая БД доступна для всех пользователей локальной сети.

Понятие сервера баз данных

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

Серверы БД, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса. В пределе, который вряд ли полностью достижим, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел. Недостаток тоже довольно очевиден. При таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная рабочая станция. Но если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления БД, разгрузив сервер, который является узким местом всей системы.

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

Базовая архитектура сервера баз данных

Типичный сервер БД отвечает за выполнение следующих функций:

- поддержание логически согласованного набора файлов;

- обеспечение языка манипулирования данными;

- восстановление информации после разного рода сбоев;

- организацию реально параллельной работы нескольких пользователей.

Непосредственное управление данными во внешней памяти

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

Управление буферами оперативной памяти

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

Управление транзакциями

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

Журнализация

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

Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда запись в журнале соответствует минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала. Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

* Язык SQL - базовый интерфейс SQL-сервера

Одним из основных преимуществ реляционного подхода к организации БД является то, что пользователи реляционных БД получают возможность эффективной работы в терминах простых и наглядных понятий таблиц, их строк и столбцов без потребности знания реальной организации данных во внешней памяти. Реляционная модель данных, содержащая набор четких предписаний к базовой организации любой реляционной системы управления базами данных (СУБД), позволяет пользователям работать в ненавигационной манере, т.е. для выборки информации из БД человек должен всего лишь указать список интересующих его таблиц и те условия, которым должны удовлетворять выбираемые данные. СУБД скрывает от пользователя выполняемые ей последовательные просмотры таблиц, выполняя их наиболее эффективным образом. Очень важная особенность реляционных систем состоит в том, что результатом выполнения любого запроса к таблицам БД является также таблица, которую можно сохранить в БД и/или по отношению к которой можно выполнять новые запросы. Базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции. В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL – Structured или Standart Query Language. До появления SQL в СУБД (независимо от того, на какой модели они основывались) приходилось поддерживать по крайней мере три языка, которые обычно имели мало общего: язык определения данных (ЯОД), служащий для спецификации структур БД; язык манипулирования данными (ЯМД), позволяющий создавать прикладные программы, взаимодействующие с БД; и язык администрирования БД (ЯАДБ), с помощью которого можно было выполнять служебные действия (например, изменять структуру БД или производить ее настройку с целью повышения эффективности). Кроме того, если требовалось предоставить пользователям СУБД интерактивный доступ к БД, приходилось вводить еще один язык, операторы которого выполняются в диалоговом режиме. Язык SQL позволяет решать все эти задачи.

Язык для взаимодействия с БД SQL появился в середине 70-х и был разработан в рамках проекта экспериментальной реляционной СУБД System R. Исходное название языка SEQUEL (Structured English Query Language) только частично отражает суть этого языка. Конечно, язык был ориентирован главным образом на удобную и понятную пользователям формулировку запросов к реляционной БД, но на самом деле являлся полным языком БД, содержащим помимо операторов формулирования запросов и манипулирования БД средства определения и манипулирования схемой БД; определения ограничений целостности и триггеров; представлений БД; структур физического уровня, поддерживающих эффективное выполнение запросов; авторизации доступа к отношениям и их полям; точек сохранения транзакции и откатов. В языке отсутствовали средства синхронизации доступа к объектам БД со стороны параллельно выполняемых транзакций: с самого начала предполагалось, что необходимую синхронизацию неявно выполняет СУБД. В настоящее время SQL реализован практически во всех коммерческих реляционных СУБД, все фирмы провозглашают соответствие своей реализации стандарту SQL, и на самом деле реализованные диалекты SQL очень близки. Особенностью большинства современных коммерческих СУБД, затрудняющей анализ существующих диалектов SQL, является отсутствие полного описания языка. Обычно описание разбросано по разным руководствам и перемешано с описанием специфических для данной системы языковых средств, не имеющих отношения к SQL. Тем не менее можно сказать, что базовый набор операторов SQL, включающий операторы определения схемы БД, выборки и манипулирования данными, авторизации доступа к данным, поддержки встраивания SQL в языки программирования и операторы динамического SQL, в коммерческих реализациях относительно устоялся и более или менее соответствует стандарту.

Деятельность по стандартизации языка SQL началась практически одновременно с появлением первых его коммерческих реализаций. Первый из числа имеющихся у автора документ датирован октябрем 1985 г. и является уже очередным проектом стандарта ANSI/ISO. Анализ доступных документов показывает, что процесс происходил очень сложно с использованием далеко не только научных доводов. В результате, принятый в 1989 г. Международный стандарт SQL во многих частях имеет чрезвычайно общий характер и допускает очень широкое толкование. В этом стандарте полностью отсутствуют такие важные разделы, как манипулирование схемой БД и динамический SQL. Многие важные аспекты языка в соответствии со стандартом определяются в реализации. Возможно, наиболее важными достижениями стандарта SQL являются четкая стандартизация синтаксиса и семантики операторов выборки и манипулирования данными и фиксация средств ограничения целостности БД, включающих возможности определения первичного и внешних ключей отношений и так называемых проверочных ограничений целостности. Средства определения внешних ключей позволяют легко формулировать требования так называемой целостности БД по ссылкам. Осознавая неполноту стандарта SQL,в марте 1992 г. - SQL2. Этот стандарт существенно более полный и охватывает практически все необходимые для реализации аспекты: манипулирование схемой БД, управление транзакциями и сессиями (сессия - это последовательность транзакций, в пределах которой сохраняются временные отношения), подключение к БД, динамический SQL, стандартизованы отношения-каталоги БД, что вообще-то не связано с языком непосредственно, но очень сильно влияет на реализацию. Одновременно с завершением работ по определению стандарта SQL2 была начата разработка стандарта SQL3. SQL3 содержит механизм триггеров и возможность использования абстрактных типов данных. (1999г.)

* Классический подход к проектированию реляционных баз данных

При проектировании БД решаются две основных проблемы:

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

- Как обеспечить эффективность выполнения запросов к БД, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования БД.

В случае реляционных БД трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Например, при работе с СУБД Ingres можно выбирать один из предлагаемых способов физической организации отношений, при работе с System R следовало бы прежде всего подумать о кластеризации отношений и требуемом наборе индексов и т.д. Поэтому в этом разделе мы ограничимся вопросами логического проектирования реляционных БД, которые существенны при использовании любой реляционной СУБД. Более того, мы не будем касаться очень важного аспекта проектирования - определения ограничений целостности (за исключением ограничения первичного ключа). Дело в том, что при использовании СУБД с развитыми механизмами ограничений целостности (например, SQL-ориентированных систем) трудно предложить какой-либо общий подход к определению ограничений целостности. Эти ограничения могут иметь очень общий вид, и их формулировка пока относится скорее к области искусства, чем инженерного мастерства. Самое большее, что предлагается по этому поводу в литературе, это автоматическая проверка непротиворечивости набора ограничений целостности. Так что будем считать, что классическая проблема проектирования реляционной БД состоит в обоснованном принятии решений о том, из каких отношений должна состоять БД и какие атрибуты должны быть у этих отношений.

Функциональные и прочие зависимости

Рассмотрим классический подход, при котором весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма (НФ) обладает свойствами лучшими, чем предыдущая. Каждой НФ соответствует некоторый определенный набор ограничений, и отношение находится в некоторой НФ, если удовлетворяет свойственному ей набору ограничений. Примером набора ограничений является ограничение первой НФ - значения всех атрибутов отношения атомарны. Поскольку требование первой НФ является базовым требованием классической реляционной модели данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию. В теории реляционных БД обычно выделяется следующая последовательность НФ: первая НФ (1NF); вторая НФ (2NF); третья НФ (3NF); НФ Бойса-Кодда (BCNF); четвертая НФ (4NF); пятая НФ, или НФ проекции-соединения (5NF или PJ/NF). Основные свойства НФ: каждая следующая НФ в некотором смысле лучше предыдущей; при переходе к следующей НФ свойства предыдущих нормальных свойств сохраняются. В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей НФ, в два или более отношения, удовлетворяющих требованиям следующей НФ. Наиболее важные на практике НФ отношений основываются на фундаментальном в теории реляционных БД понятии функциональной зависимости. Для дальнейшего изложения нам потребуются несколько определений. (Заметим, что везде ниже под термином "атрибут X (Y, Z, ...)", понимается некоторое подмножество атрибутов отношения, или "составной" атрибут.)

Функциональная зависимость. В отношении R атрибут Y функционально зависит от атрибута X (X и Y м.б. составными) в том и только в том случае, если кажд. значению X соотв. в точности одно значение Y: R.X-->R.Y.

Полная функциональная зависимость. Функциональная зависимость R.X-->R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.

Транзитивная функциональная зависимость. Функциональная зависимость R.X-->R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X-->R.Z и R.Z-->R.Y и отсутствует функциональная зависимость R.Z-->R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)

Неключевой атрибут. Некл. атрибутом называется любой атрибут отношения, не входящий в состав ключа (в частности, первичного).

Взаимно независимые атрибуты. Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

Проектирование реляционных баз данных на основе принципов нормализации

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

Вторая НФ. (В этом определении предполагается, что единственным ключом отношения является первичный ключ.)

Отношение R находится во второй НФ (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.

Третья НФ. (Снова определение дается в предположении существования единственного ключа.)

Отношение R находится в третьей НФ (3NF) в том и только в том случае, если находится в 1NF и каждый неключевой атрибут не является транзитивно зависимым от какого-либо ключа R.

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

НФ Бойса-Кодда. Отношение R находится в НФ Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом. Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.

Четвертая НФ. Отношение R находится в четвертой НФ (4NF) в том и только в том случае, если в случае существования многозначной зависимости A -->> B все остальные атрибуты R функционально зависят от A.

В отношении R (A, B, C) существует многозначная зависимость R.A -->> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

Пятая НФ. Отношение R находится в пятой НФ (НФ проекции-соединения - PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R. Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.

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

* CASE-системы для проектирования информационных систем

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

Назначение и разновидности CASE-систем

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

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

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

- использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл программного обеспечения) содержит следующие компоненты:

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

- графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ER-диаграмма и др.), образующих модели информационных систем;

- средства разработки приложений, включая языки 4GL и генераторы кодов;

- средства конфигурационного управления;

- средства документирования;

- средства тестирования;

- средства управления проектом;

- средства реинжиниринга.

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

- применяемым методологиям и моделям систем и БД;

- степени интегрированности с СУБД;

- доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

- средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

- средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

- средства проектирования БД, обеспечивающие моделирование данных и генерацию схем БД (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE), а также Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

- средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

- средства реинжиниринга, обеспечивающие анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ER-диаграмм входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке Си++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

- средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

- средства конфигурационного управления (PVCS (Intersolv));

- средства тестирования (Quality Works (Segue Software));

- средства документирования (SoDA (Rational Software)).

Наиболее развитые CASE-средства:

Silverrun - CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования информационных систем бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь"). Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

JAM - Средство разработки приложений JAM (JYACC's Application Manager) - продукт фирмы JYACC (США). Основной чертой JAM является его соответствие методологии RAD, поскольку он позволяет достаточно быстро реализовать цикл разработки приложения, заключающийся в формировании очередной версии прототипа приложения с учетом требований, выявленных на предыдущем шаге, и предъявить его пользователю.

Vantage Team Builder (Westmount I-CASE) представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

Uniface - Uniface 6.1 - продукт фирмы Compuware (США) - представляет собой среду разработки крупномасштабных приложений в архитектуре "клиент-сервер". Объявленная в конце 1996 г. версия Uniface 7 полностью поддерживает распределенную модель вычислений и трехзвенную архитектуру "клиент-сервер" (с возможностью изменения схемы декомпозиции приложений на этапе исполнения). Приложения, создаваемые с помощью Uniface 7, могут исполняться в гетерогенных операционных средах, использующих различные сетевые протоколы, одновременно на нескольких разнородных платформах (в том числе и в Internet). Среда функционирования Uniface - все основные UNIX - платформы и MS Windows.

Designer/2000 + Developer/2000 - CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного жизненного цикла программного обеспечения для систем, использующих СУБД ORACLE.

Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)

ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД.

BPwin - средство функционального моделирования, реализующее методологию IDEF0.

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД. S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных.

Объектно-ориентированные CASE-средства (Rational Rose)

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (Си++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/Си++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на Си++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

В этой части мы рассмотрим вопросы организации специального класса информационных приложений, ориентированных не на оперативную обработку транзакций (On-Line Transaction Processing - OLTP), а на оперативную аналитическую обработку (On-Line Analitical Processing - OLAP). У этих двух разновидностей систем принципиально разные задачи. Корпоративные информационные OLTP-системы создаются для того, чтобы способствовать повседневной деятельности корпорации, и опираются на актуальные для текущего момента данные. OLAP-системы служат для анализа деятельности корпорации или ее компонентов и прогнозирования будущего состояния. Для этого требуется использовать многочисленные накопленные данные о деятельности корпорации в прошлом, а также внешние источники данных, формирующие контекст, в котором работала корпорация.

Система оперативной аналитической обработки данных отличается от статической системы поддержки принятия решений (Decision Support System - DSS) тем, что OLAP-система позволяет аналитику динамически формировать класс вопросов, который требуется для решаемой им текущей аналитической задачи. DSS обеспечивает выдачу отчетов в соответствии с заранее сформулированными правилами. Для удовлетворения нового запроса нужно формально его описать, запрограммировать и только потом выполнить.

Тематика OLAP-систем очень широка и специальна. Мы не будем обсуждать соответствующие вопросы на глубоком уровне, а в основном (и тоже не очень глубоко) сосредоточимся на проблемах обеспечения OLAP-системы данными. Мы будем говорить о складах данных (Datawarehouse).

Эта часть курса главным образом основана на статьях А. Сахарова, опубликованных в журнале "СУБД" (номера 3 и 4 за 1996 г.), а также на книге Harjinder Gill и Prakash Rao "The Official Guide to Data Warehousing" (Que Corporation, 1996 г.).

6.1. Проблема интеграции данных

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

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

Итак, в основе концепции склада данных лежат две основные идеи:

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

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

Остановимся на некоторых проблемах реализации складов данных:

неоднородность программной среды;

распределенный характер организации;

повышенные требования к безопасности данных;

необходимость наличия многоуровневых справочников метаданных;

потребность в эффективном хранении и обработке очень больших объемов информации.

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

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

Собранная вместе согласованная информация об истории развития корпорации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка дает возможность анализа прошлой и текущей деятельности корпорации и построения прогнозов для будущего. Эта информация настолько ценна для корпорации, что нельзя допустить возможности ее утечки (на самом деле, если склад данных одной корпорации попадет в руки аналитиков другой корпорации, то все аналитические прогнозы первой корпорации сразу станут неверными). В системах, основанных на складах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД (этот уровень защиты соответствует классу C2 в соответствии с классификацией Оранжевой Книги Министерства обороны США). Для обеспечения должного уровня защиты доступ к данным должен контролироваться не только на уровне таблиц и их столбцов, но и на уровне отдельных строк (это уже соответствует классу B1 Оранжевой Книги). Приходится также решать вопросы аутентификации пользователей, защиты данных при их перемещении в склад данных из оперативных баз данных и внешних источников, защиты данных при их передаче по сети.

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

Описания структур данных, их взаимосвязей.

Информация о хранимых на складе данных и поддерживаемых им агрегатах данных.

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

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

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

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

Уже сейчас известны примеры складов данных, содержащих терабайты информации. По данным консалтинговой компании Meta Group, около половины корпораций, использующих или планирующих использовать склады данных, предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте баз данных этот коэффициент увеличивается.

Последнее, на чем мы остановимся в этом разделе, - это рынки данных (Data Mart; кстати, ведущий специалист Московского отделения компании Informix Ховард Залкин предпочитает называть их "лавками данных"). Рынок данных по своему исходному определению - это набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации. По сути дела, рынок данных - это облегченный вариант склада данных, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Рынок данных, естественно, существенно меньше по объему, чем корпоративный склад данных, и для его реализации не требуется особо мощная вычислительная техника.

В последнее время все более популярной становится идея совместить концепции склада и рынка данных в одной реализации и использовать склад данных в качестве единственного источника интегрированных данных для всех рынков данных. Тогда естественной становится такая трехуровневая организация OLAP-системы:

На первом уровне реализуется корпоративный склад данных на основе одной из развитых современных реляционных СУБД. Это хранилище интегрированных в основном детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных.

На втором уровне поддерживаются рынки данных на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server). В этом курсе мы не рассматриваем особенности организации многомерных СУБД (это отдельная большая тема), но заметим, что такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-20 гигабайт). В данном случае это и не требуется, поскольку речь идет о рынках данных. Заметим, что рынок данных не обязательно должен быть полностью сформирован. Он может содержать ссылки на склад данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.

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

6.2. Подходы и имеющиеся решения

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

6.2.1. Компания IBM

Решение компании IBM называется A Data Warehouse Plus. Целью компании является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой складов данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в склад данных, находятся в системах IBM. Поэтому естественная тесная интеграция программных продуктов.

Предлагаются три решения для складов данных:

Изолированный рынок данных. Предназначен для решения отдельных задач вне связи с общим хранилищем корпорации.

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

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

6.2.2. Oracle

Решение компании Oracle в области складов данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области складов данных базируются на следующих составляющих:

наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей складов данных;

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

высокий технологический потенциал компании в области анализа данных;

доступность ряда продуктов, производимых другими компаниями.

6.2.3. Hewlett Packard

Работы, связанные со складами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения складов данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления складами данных. Основа построения складов данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.

6.2.4. Sybase

Стратегия компании в области складов данных основывается на разработанной ей архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей складов данных (например, введена побитная индексация).

6.2.5. Informix Software

Стратегия компании в отношение складов данных направлена на расширение рынка для ее продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура склада данных базируется на четырех технологиях: реляционные базы данных, программном обеспечении для управления складом данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения складов данных.

6.2.6. AT&T GIS

Решение компании направлено на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.

6.2.7. SAS Institute

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

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

преобразование данных и манипулирование ими с использованием 4GL;

наличие сервера многомерных баз данных;

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

6.2.8. Software AG

Деятельность компании в области складов данных происходит в рамках программы Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления складом данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в склад данных.

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