Предыдущая страница реферата | 9  10  11  12  13  14  15  16  17  18  19 | Следующая страница реферата

. Помимо стандартных типов данных 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; обеспечивают возможности частичного переноса логики приложений на сторону сервера за счет использования ограничений целостности, триггеров и хранимых процедур.
Существует масса приложений, для которых возможностей современных серверов баз данных хватает с запасом. Это традиционные банковские приложения, системы резервирования билетов и мест в гостиницах, системы управления предприятиями, библиотечные информационные системы и т.д. Основными претензиями со стороны разработчиков таких систем к поставщикам СУБД является не то, что СУБД не может что-то сделать, а то, что она может сделать слишком много, в том числе вещи, абсолютно ненужные данному приложению.
Например, очевидно, что библиотечная информационная система должна быть в состоянии обслуживать одновременно многих пользователей. Но эти пользователи почти всегда только читают информацию, а изменения данных происходят сравнительно редко и не обязательно на фоне продолжающегося оперативного доступа к данным. Конечно, требуется развитый механизм эффективно реализуемых запросов. Тем не менее, используемая СУБД будет включать общие средства управления транзакциями со всеми разновидностями блокировок. И это общая ситуация. Чем большими возможностями обладает СУБД, тем большему числу приложений не потребуется хотя бы часть этих возможностей. При этом сервер остается монолитом, стоит одних и тех же денег и требует для своего использования практически одни и те же ресурсы.
Существует много приложений, для которых средства, предоставляемые традиционными реляционными серверами баз данных, недостаточны. Основной характеристикой таких приложений является потребность в обработке сложноструктурированных объектов, для представления которых средствами реляционных систем требуется использование многочисленных таблиц, над которыми при выполнении приложения приходится выполнять операции соединения. Классическими примерами подобных приложений являются системы автоматизированного проектирования, системы поддержки принятия решений и т.д. Известно, что операция соединения является наиболее трудоемкой в реляционных системах. Время выполнения операции и количество требуемых операций возрастают нелинейно при увеличении размера и числа соединяемых таблиц. Кроме того, и для приложений этой категории часто не требуются все возможности, поддерживаемые сервером баз данных.
Таким образом, мы видим, что несмотря на наличие высокопроизводительных серверов реляционных баз данных, обладающих развитыми возможностями в соответствии с реляционным подходом, в мире информационных приложений существует определенная неудовлетворенность. Компании, производящие СУБД, ощущают эту неудовлетворенность, и чтобы не потерять рынок в будущем, пытаются придать своим продуктам новые качества.
8.1.3. Преобразование реляционного подхода к организации баз данных в объектно-реляционный подход
Мы уже отмечали в начале этого раздела, что радикальным решением всех проблем, свойственных реляционным системам, был бы революционный переход к объектно-ориентирован- ной организации как баз данных, так и систем управления ими. Мы перечислили ряд причин, по которым массовых потребителей баз данных не устроила эта возможная революция. Но дело не только в этом. В конце 1989 г. группа ведущих специалистов в области объектно-ори- ентированных баз данных опубликовала "Манифест объектно-ориентированных баз данных" (перевод на русский язык опубликован в журнале "СУБД", N 4, 1995 г.).
В этом манифесте утверждается, что современная ситуация с ООБД напоминает ситуацию с реляционными системами середины 1970-х гг. При наличии большого количества экспериментальных проектов (и коммерческих систем) отсутствует общепринятая объектно-ориенти- рованная модель данных, и не потому, что нет ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле, имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
Объектно-реляционный подход возник как эволюционная альтернатива революционному объектно-ориентированному подходу. Заметим, что термин
"объектно-реляционные СУБД" вошел в обиход далеко не сразу, и даже сейчас системы соответствующего класса часто характеризуются другими терминами.
Точкой отсчета можно считать опубликование в 1990 г. "Манифеста систем баз данных третьего поколения" (перевод на русский язык опубликован в журнале
"СУБД", N 2, 1995 г.). В этом манифесте выдвигалась идея и обосновывались преимущества эволюционного развития возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения. Частично требования к системам следующего поколения включали просто необходимость реализации давно известных свойств, которые отсутствовали в большинстве текущих реляционных СУБД (ограничения целостности общего вида, триггеры, модификация БД через представления и т.д.). В число новых требований входили полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.
Другим термином, используемым по отношению к СУБД третьего поколения является термин "расширяемые СУБД". Под этим словосочетанием понимается то, что компания-производи- тель поставляет некоторый базовый остов системы, функции которой в дальнейшем могут на- ращиваться сторонними компаниями или даже пользователями.
Термин "объектно-реляционная СУБД" был внедрен в обиход Майклом
Стоунбрейкером, идейным руководителем проектов свободно распространяемых систем Ingres и Postgres и основателем компании Illustra, выпустившей одноименный коммерческий продукт. (На самом деле, система Illustra является хорошо отлаженным и документированным вариантом Postgres). В Postgres были реализованы многие интересные средства, свойственные системам третьего поколения: поддерживалась темпоральная модель хранения и доступа к данным и в связи с этим был абсолютно пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоев; обеспечивался мощный механизм ограничений целостности; имелась возможность хранения в столбцах таблицы вложенных таблиц. Допускалось хранение в полях таблицы данных абстрактных, определяемых пользователями типов, что обеспечивало возможность внедрения в базу данных поведенческого аспекта.
Наконец, ведущие компании-производители СУБД стали использовать для идентификации своих серверных продуктов нового поколения термин
"универсальный сервер", имея в виду, что в этих продуктах используется объектно-реляционный подход, а также обеспечиваются возможности расширяемости, интеграции с Internet и т.д.
8.1.4. Первые серверные продукты, поддерживающие объектно-реляционный подход
С конца 1996 г. три компании объявили о выпуске серверных продуктов, соответствующих названию "универсальный сервер": Oracle с продуктом Oracle
8, Informix с продуктом InformixUniversalServer и IBM с продуктом DB2
UniversalDatabase. Далее мы приведем краткие характеристики этих систем.
8.1.4.1. Oracle 8
Компания Oracle заявляла, что Oracle 8 будет уметь делать с объектами все, что умеет делать InformixUniversalServer, и даже больше. Однако это не так в первом выпуске Oracle 8 (этот выпуск был официально объявлен 24 июня 1997 г.). В фокусе Oracle 8 находятся расширенная система типов и поддержка бизнес-объектов; появление других возможностей расширяемости ожидается в версии 8.1. Oracle концентрируется на реализации своей сетевой вычислительной архитектуры (NCA - NetworkComputingArchitecture), и в Oracle
8 вносятся улучшенные возможности производительности, масштабируемости, доступности, репликации, разделения дан- ных и т.д.
NCA - это трехзвенная архитектурная структура, основанная на CORBA
(CommonObjectRequestBrokerArchitecture - Общая архитектура брокера объектных заявок). В NCA используются расширяющие компоненты, называемые
"картриджами", которые могут разрабатываться Oracle или сторонними поставщиками. Впервые использование картриджей приложений и картриджей баз данных потребовалось в OracleWebApplicationServer для организации связи на основе CORBA. В контексте расширяемой среды данных Oracle обеспечивает компоненты на уровне промежуточного программного обеспечения приложений
(например, компонент управления транзакциями в WebApplicationServer) и на уровне универсального сервера (Oracle 8). На объектном уровне Oracle 8 поддерживает объектные представления данных с использованием новых объектных типов и существующих реляционных данных. Кроме того, Oracle 8 поддерживает объектный кэш на стороне клиентов и навигацию между объектами по ссылкам. Транслятор объектных типов отображает объекты базы данных в соответствующие конструкции языка Си.
Далее приводится сводка свойств, имеющихся в Oracle 8 и ожидаемых в версии
8.1:

. Расширяемая система типов. Поддерживаются объектные типы, типы коллекций (массивы переменного размера и вложенные таблицы) и ссылочные типы. Объектный тип может применяться либо к столбцу, либо к строке и может быть семантически эквивалентен именованному строчному типу SQL-3. Кроме того, Oracle 8 явно связывает с объектными типами методы. Пока поддерживается только один уровень вложенности таблиц (в

8.0) и не реализована полная инкапсуляция определяемых пользователями типов данных. В версии 8.1 будет поддерживаться одиночное наследование. Не предполагается возможность репликации расширенных данных.

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

. Расширяемая система индексации. Поддержка определяемых пользователями индексных структур и индексов на выражениях появится вместе с компонентом DatabaseExtensibilityServices.

. Расширяемый оптимизатор. Возможность указывать стоимость выполнения определенных пользователями функций и обеспечивать статистику об использовании определенных пользователями данных ожидается с появлением компонента DatabaseExtensibilityServices. К расширенным типам пока не применяются параллельные операции.

. Большие объекты и внешние данные. LOB могут храниться внутри базы данных или во внешних файлах. Oracle 8 не поддерживает доступа по записи к внешним данным и не гарантирует их целостность. Большие объекты могут быть реплицированы, но таблицы с LOB реплицировать нельзя.

Рекомендуем скачать другие рефераты по теме: реферат религия, оценка дипломной работы.





Предыдущая страница реферата | 9  10  11  12  13  14  15  16  17  18  19 | Следующая страница реферата