Реферат: Корпоративные сети

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

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

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

В CA-OpenIngres поддерживаются стандарты SQL-89 и ядерный уровень языка SQL-92. (Обратите внимание, что никто из ведущих производителей не гарантирует полной совместимости с SQL-92. Это очень плохо, поскольку уже на протяжении более чем 4 лет, ни одна компания не может или не хочет произвести продукт, полностью соответствующий требованиям хорошего международного стандарта. Правда, и стандарт несколько сложноват.)

Очень интересным направлением развития линии CA-OpenIngres явилось приобретение японской объектно-ориентированной СУБД Jasmin. Это оригинальная объектно-ориентированная система, модель данных которой основывается одновременно на идеях Smalltalk и Си++. Компания ComputerAssociates считает, что в принципе невозможно сочетать в одной системе объектно-ориентированный и реляционный подходы (в частности, отметим по-прежнему существующую проблему потери соответствия объектных и реляционных операций, присущую объектно-реляционным системам).

Поэтому в ближайших планах компании содержатся намерения одновременного поддержания объектно-ориентированного и реляционного интерфейсов доступа к базам данных, среда хранения которых будет поддерживаться OpenIngres. Сама же СУБД OpenIngres поддерживает возможности шлюзования для доступа к унаследованным системам баз данных (в частности, IDMS), что обеспечивает полную преемственность по отношению к ранее разработанным и накопленным хранилищам данных. К сожалению, в текстах, распространяемых компанией CA, содержится слишком мало технической информации относительно Jasmin. Однако достоверно известно, что объектно-ориентированные возможности управления данными широко используются в новом продукте компании, предназначенном для управления и администрирования глобально распределенных корпоративных приложений и называемом TNG (TheNextGenerationofUniCenter).

В июне 1997 г. компания CA объявила о выпуске новой версии OpenIngres 2.0. Кроме улучшенных возможностей репликации и наличия развитых средств интеграции с Internet, в OpenIngres появились следующие новые возможности:

1. использование блокировок на уровне записи с возможностью выбора вида блокировок для указанных таблиц или для указанных пользователей;
2. поддержка правил (триггеров) уровня оператора со срабатыванием правила для данного оператора один раз независимо от числа затрагиваемых им строк;
3. реализация всех четырех уровней изоляции транзакций, специфицированных в стандарте языка SQL (READCOMMITTED, REPEATABLEREAD, SERIALIZABLE и READUNCOMMITTED);
4. наличие средств параллельного копирования базы данных, хранимых на дисковых накопителях с разными контроллерами;
5. улучшенные средства управления пространственными данными, включая индексацию на основе R-деревьев;
6. возможность выбора размера страницы для хранения индивидуальной таблицы;
7. более строгая оптимизация на основе развитой статистической информации, позволяющей, в частности, оценить размер результата соединения таблиц.

Кроме того, в версии 2.0 улучшены средства визуального администрирования базы данных.

О конкретных работах, связанных с интеграцией с объектно-ориентированной СУБД Jasmine, пока не сообщается.

8.1.1.5. Серверные продукты линии DB2 компании IBM

Серьезные практические исследования в области систем управления реляционными базами данных компания IBM начала с проекта экспериментальной системы SystemR, которая разрабатывалась в исследовательской лаборатории фирмы IBM в 1975-1979 г.г. Эта работа оказала революционизирующее влияние на развитие теории и практики реляционных систем во всем мире. Именно SystemR практически доказала жизнеспособность реляционного подхода к управлению базами данных.

После успешного завершения работ по созданию этой системы и получения экспериментальных результатов ее использования был разработан целый ряд коммерчески доступных реляционных систем, в том числе и на основе непосредственного развития SystemR (возможности одной из коммерчески доступных реляционных систем - DB2 описываются в переведенной на русский язык книге К. Дейта "Руководство по реляционной СУБД DB2", хотя книга существенно отстала от практики; ее прекрасный перевод на русский язык вышел в свет в 1988 г.). Исключительно важен опыт, приобретенный при разработке этой системы. Практически во всех более поздних реляционных СУБД в той или иной степени используются методы, примененные в SystemR.

На наш взгляд, компания IBM много потеряла, ориентируя DB2 только на использование своих аппаратно-программных платформ. Первый вариант DB2 работал на IBM/370 в операционной среде OS/370. В связи с развитием аппаратуры и программного обеспечения мейнфреймов система была перенесена в операционную среду MVS. Программное обеспечение специализированного аппаратно-программного комплекса AS/400 также во многом основано на DB2. После разработки операционной системы OS/2 появился вариант DB2, пригодный для использования на персональных компьютерах. СУБД DB2 всегда представляла собой развитый программный продукт управления реляционными базами данных. В ней всегда присутствовали, в частности, такие возможности как управление транзакциями, журнализация изменений и восстановление согласованного состояния базы данных после сбоев программного обеспечения и/или аппаратуры. Заметим, что именно IBM выпустила первый корпоративный стандарт языка SQL.

Развитие системы и сферы ее применений ограничивало то, что отсутствовал мобильный текст системы. Ориентируясь на использование DB2 на своих аппаратных платформах, компания IBM исторически использовала для программирования DB2 смесь языка ассемблера и языка PL/1. Прорывом как для DB2, так и для IBM в целом стало появление Unix-ориентированной серии серверов и рабочих станций RS/6000. Именно при создании варианта системы DB2/6000 компания была вынуждена переписать систему на языке Си. После этого появилась очевидная возможность простого переноса СУБД на другие аппаратные платформы. В последнее время IBM объявила выпуск DB2 для аппаратно-программных платформ Sun и HP. По мнению автора курса, этот шаг означает появление на рынке независимых серверных продуктов управления реляционными базами данных очень серьезного и достойного конкурента. Коротко охарактеризуем основные возможности наиболее распространенной в настоящее время версии DB2 Version 2:

1. Возможности, соответствующие требованиям реляционной модели данных:

• Поддерживаются почти соответствующие полному стандарту SQL-92 средства обеспечения ссылочной целостности. Для таблицы-предка можно объявить правила удаления строк Restrict, NoAction, Cascade или SetNulls, в соответствии с которыми будут обрабатываться соответствующие строки таблицы-потомка. (При применении правила Restrict будет запрещено удаление строки таблицы-предка, если на эту строку ссылается хотя бы одна строка таблицы-потомка; задание правила Cascade приводит к автоматическому удалению ссылающихся строк таблицы-потомка; при указании правила SetNulls в поле ссылки ссылающихся строк автоматически устанавливаются неопределенные значения; правило NoAction, которое действует подобно правилу Restricted, но с другим диагностическим сообщением, устанавливается при определении ограничений ссылочной целостности по умолчанию).
• Возможно определение пользователем значений полей таблицы по умолчанию. Вообще-то эта возможность определена в SQL-92, и ее реализация не доставляет особого труда, но тем не менее в большинстве систем такая возможность отсутствует.
• Наконец-то реализовано средство, задаваемое фразой WITHCHECKOPTION при определении представления. При указании такого требования становится невозможным занести строку в представляемую таблицу или изменить существующую строку таким образом, чтобы полученная строка не была видима через представление.

2. Объекты базы данных:

• Помимо стандартных типов данных DB2 допускает хранение BLOBs размером до 2 Гб. Соответствующие поля предназначены для сохранения мультимедийной информации, структура которой известна только приложению.
• Поддерживается развитый механизм триггеров с возможностью указания степени гранулированности триггера, например, должно ли срабатывать заданное действие один раз при выполнении операции строки из заданной таблицы, или его следует выполнять для каждой удаляемой строки.
• Обеспечивается механизм хранимых процедур, которые программируются на смеси языков SQL и одного из процедурных языков третьего поколения.

3. Возможности запросов:

• Реализованная версия языка SQL является расширенным множеством ядерного уровня языка SQL-92 и включает ряд конструкций, наличие которых предполагается в SQL-3.
• Поддерживаются все разновидности соединений, определенные в SQL-92, но синтаксис соответствующих конструкций отличается от стандартного.

4. Поддержка доступа из Internet:

• Специальный шлюз, встроенный в сервер, обеспечивает доступ к данным DB2, транслируя команды HTML в операторы языка SQL.

IBM активно ведет работу по созданию собственного универсального сервера. С августа 1997 г. доступна бета-версия DB2 UniversalDatabase. Этот продукт относится к категории объектно-реляционных, и мы кратко обсудим его возможности позже.

8.1.1.6. Серверные продукты управления базами данных компании Microsoft

Первые работы компании Microsoft, относящиеся к области баз данных, проводились совместно с компанией Sybase, причем Microsoft поддерживала линию OS/2, а Sybase - UNIX. Так продолжалось до 1992 г., когда компания Microsoft приняла решение о переносе SQL-сервера на платформу WindowsNT. (Заметим, кстати, что недаром серверные продукты Sybase и Microsoft называются SybaseSQLServer и MicrosoftSQLServer соответственно; у этих продуктов общие корни.) Перенос SQL сервера в среду NT сопровождался существенными переделками ядра системы и в основном был выполнен специалистами Microsoft. Первая по-настоящему работоспособная версия сервера (MSSQLServer 4.21) вышла в свет в 1994 г. для использования в среде NT 3.5. Особое внимание обращалось на развитие средств администрирования, внедрение (в час- тности, и для собственного использования) механизма хранимых процедур и т.д. В 1995 г. была выпущена версия 6.0, в которой был внедрен ряд средств, обеспечивающих удобные взаимодействия с другими продуктами Microsoft. Наконец, в 1996 г. появилась наиболее современная версия 6.5.

Перечислим основные возможности MicrosoftSQLServer 6.5:

1. в ядре сервера может выполняться несколько нитей, что позволяет эффективно использовать симметричные мультипроцессорные компьютеры (SMP - SymmetricMultiprocessorProcessors);
2. поддерживается асинхронное выполнение обменов с несколькими дисковыми устройствами;
3. обеспечивается параллельное выполнение пользовательских транзакций, операций построения индексов и загрузки данных, а также резервного копирования;
4. при оптимизации запросов используется статистическая информация;
5. для синхронизации параллельного доступа применяется механизм блокировок на уровне записи с автоматическим распознаванием и разрешением тупиковых ситуаций;
6. поддерживается автоматическая репликация данных на основе журнальной информации или мгновенных снимков, включая доступность репликации в базы данных, доступные через интерфейс ODBC, и репликации "массивных" данных (типов TEXT и IMAGE);
7. обеспечивается двухфазная фиксация распределенных транзакций;
8. реализованы операции CUBE и ROLLUP для работы с многомерными данными в системах оперативной аналитической обработки (OnLineAnalyticalProcessing - OLAP);
9. доступны средства интеграции с системами электронной почты, в частности, с MicrosoftExchangeServer;
10. имеются средства, обеспечивающие доступ к SQL-серверу из Web-серверов и формирование результатов запросов в формате HTML (WebConnector и WebAssistant);
11. развиты возможности администрирования баз данных: SQLEnterpriseManager позволяет с одного терминала управлять произвольным числом SQL-серверов; дополнительные административные процедуры могут разрабатываться на VisualBasic со встроенным SQL;
12. реализован входной уровень стандарта SQL-92 и важные компоненты промежуточного уровня;
13. можно использовать национальные символы, в том числе символы русского языка.

Microsoft не объявляет о планах перехода к использованию объектно-реляционного подхода. Пока развитие SQL-сервера происходит в рамках все большего внедрения в этот продукт компонентов, основанных на общей объектной архитектуре COM (ComponentObjectArchitecture - компонентная объектная архитектура). Основываясь на спецификациях OLE (ObjectLinkingandEmbedding - связывание и встраивание объектов), которые обеспечивают объектное представление различных сервисов операционной системы, а также развитие OLE - OLEDB, компания Microsoft пытается обеспечить пользователям общую объектную среду компонентов (включая данные, поддерживаемые SQL-сервером, которые могут разнообразным образом комбинироваться).

8.1.2. Насколько возможности серверов баз данных соответствуют потребностям приложений?

Как мы отмечали в вводной части этого раздела, реляционные базы данных обладают достоинствами и недостатками. Для некоторых приложений перевешивают достоинства, для других - недостатки. Можно сказать, что современные серверы реляционных баз данных (такие как Infor- mixOnLine версии 6 и выше, Oracle 7.x, SybaseV.11) обладают качествами, близкими к предельно возможным при использовании традиционной технологии. Еще возможны совершенствование оптимизации запросов, применение более эффективных методов распараллеливания, реализация более высоких уровней стандарта SQL и т.д., но принципиально при этом ничего не изменится. Реляционные СУБД могут управлять очень большими базами данных; эффективно используют возможности симметричных и массивно параллельных компьютеров; позволяют хранить в таблицах текстовую и графическую информацию произвольного размера; поддерживают достаточно развитое подмножество языка SQL; обеспечивают возможности частичного переноса логики приложений на сторону сервера за счет использования ограничений целостности, триггеров и хранимых процедур.

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31