Роль и место банков данных в информационных системах; (Занозин Алексей)

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

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

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

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

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

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

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

Известно немало предложений, ориентированных на обеспечение мобильности программ. Среди них:

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

·
снабжение каждой ПЭВМ компиляторами для всех языков программирования при установлении надлежащих языковых стандартов;

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

·
использование сетей ПЭВМ в предположении, что хотя бы один из компьютеров сети обладает необходимым компилятором.

Рассмотрим вопрос о целесообразности применения перечисленных подходов к обеспечению мобильности программ по отношению к СУБД:

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

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

3. В случае СУБД сеть ПЭВМ не решает проблемы: здесь требуется не только компиляция и выполнение программы, но и доступ к вполне определенной базе данных, организованной средствами конкретной СУБД.

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

Модели данных играют значительную роль в системах управления базами данных:

·
являются ключевыми компонентами архитектуры СУБД;

·
служат основой разработки семейств языков высокого уровня для взаимодействия с базами данных (языков программирования, запросных языков, языков диалога);

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

·
являются средством обеспечения эволюции баз данных.

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

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

При этом перспективным считается следующий подход:

·
преобразование исходной модели данных в целевую выражается в преобразовании схем и состояний конкретных баз данных в схемы и состояния баз данных в целевой модели данных;

·
преобразование операторов языка манипулирования данными (ЯМД) целевой модели в последовательность операторов исходной модели данных.

Существующие технологии интеграции баз данных основаны на использовании реляционной модели данных (ODBC, BDE и др.), что обеспечивает достижение схемной однородности по определению. Применение указанных технологий позволяет говорить о возможности формирования профессионального уровня схемной интеграции распределенных баз данных. На схемном интеграционном уровне решаются задачи табличного представления данных независимо от специфики определения локальных баз данных в средах различных систем управления базами данных (СУБД), например, таких как Paradox, FoxPro, Oracle, Access и др.

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

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

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

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

Следующим важным аспектом является то, что базы данных призваны хранить больше, чем только числа и текстовые строки. Они должны использоваться для хранения многих видов объектов, которые характерны для технологии WWW, и связей между этими объектами. Различие между базой данных и остальной частью Web становится неясным. Каждый поставщик баз данных обещает «универсальный сервер», который будет хранить и анализировать все типы данных (все библиотеки классов и соответствующие объекты).

Унификация процедур и данных расширяет традиционную вычислительную модель «клиент-сервер» в двух перспективных направлениях:

·
активные базы данных;

·
потоки работ.

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

Особое внимание следует уделить реляционным базам данных. Реляционные базы данных позволяют эффективно работать в архитектуре «клиент-сервер». Приложение «клиент-сервер» разбивается на две части. Клиентская часть отвечает за поддержку ввода и представление выводных данных для пользователя или клиентского устройства. Сервер отвечает за хранение базы данных, обработку клиентских запросов к базе данных, возврат клиенту общего ответа.
Реляционный интерфейс особенно удобен для использования в архитектуре «клиент-сервер», поскольку приводит к обмену высокоуровневыми запросами и ответами. Высокоуровневый интерфейс SQL минимизирует коммуникации между клиентом и сервером. Сегодня многие «клиент-серверные» средства строятся на основе протокола ODBC, который обеспечивает для клиента стандартный механизм запросов высокого уровня к серверу. Парадигма «клиент-сервер» продолжает развиваться. Наблюдается возрастающая тенденция интеграции процедур в серверах баз данных. В частности, такие процедурные языки, как BASIC и Java, были добавлены к серверам, чтобы клиенты могли вызывать прикладные процедуры, выполняемые на сервере.
Параллельная обработка баз данных была вторым неожиданным преимуществом реляционной модели. Отношения являются однородными множествами записей. Реляционная модель включает набор операций, замкнутых по композиции: каждая операция получает отношения на входе и производит отношение как результат. Поэтому реляционные операции естественным образом предоставляют возможности конвейерного параллелизма путем направления вывода одной операции на вход следующей.
Реляционные данные также хорошо приспособлены к графическим пользовательским интерфейсам (GUI). Очень легко представлять отношение как множество записей – к отношениям пригодна метафора электронных таблиц. Пользователи могут просто создавать отношения в виде электронных таблиц и визуально манипулировать ими. На самом деле имеется много инструментальных средств, позволяющих перемещать данные между документами, электронными таблицами и базами данных. Явно и единообразно представленные данные, связи и метаданные делают это возможным.
Реляционные системы, объединенные с GUI, позволяют сотням или тысячам людей каждый день формулировать сложные запросы к базам данных. Комбинация GUI и реляционных систем подходит ближе всего к достижению цели автоматического программирования. GUI позволяют просто конструировать сложные запросы. Для заданного непроцедурного запроса реляционные системы находят наиболее эффективные способы его выполнения.
Если проанализировать историю развития СУБД, можно отметить, что к 1995 году Oracle, Informix и Ingress принесли на рынок свои системы управления реляционными базами данных. Через несколько лет на рынке появились продукты IBM и Sybase. К 2000 году реляционные системы стали более популярными, чем предшествовавшие им ориентированные на наборы записей навигационные системы.
Между тем файловые системы и системы, ориентированные на наборы, оставались рабочими лошадками многих корпораций. С годами эти корпорации построили громадные приложения и не могли легко перейти к использованию реляционных систем. Реляционные системы скорее стали ключевым средством для новых «клиент-серверных» приложений.