Краткий обзор коммерческих баз данных

С.М. Солдатов,  соискатель, руководитель Л.И. Абросимов доктор технических наук, профессор (МЭИ)

 

1. Классификация БД. Модели представления данных.

1.1. Дореляционные модели представления данных.

1.1.1. Иерархическая модель данных.

1.1.1.1. Структура данных.

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

•  Атрибут (элемент данных) - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

• Запись - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов

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

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

При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами (диаграмма Бахмана).[2]

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

1.1.2. Сетевая модель данных.

1.1.2.1. Структура данных.

На разработку этого стандарта большое влияние оказал американский ученый Ч. Бахман. Основные принципы сетевой модели данных были разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.).

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

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

 

1.2. Реляционные базы данных.

 

1.2.1. Реляционная модель данных.

Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970г [3]. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

1.2.1.1. Структура данных.

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф.Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").

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

Определения:

•  Декартово произведение: Для заданных конечных множеств,,…, (не обязательно различных) декартовым произведением **…*называется множество произведений вида: , где .

•  Отношение: Отношением R, определенным на множествах,,…,, называется подмножество декартова произведения **…*. При этом:

• множества ,,…,называются доменами отношения
• элементы декартова произведения называются кортежами
• число n определяет степень отношения (n=1 - унарное, n=2 - бинарное, ..., n-арное)
• количество кортежей называется мощностью отношения

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

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

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

Именованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет собой схему базы данных.

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

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

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

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

2. Коммерческие реляционные базы данных

 

2.1. Основные тенденции рынка СУБД

 

В 1999 году компанией Gartner Group выявлена основная тенденция рынка СУБД, которая выражается следующей фразой:

“Enterprise DBMS Market: From Big Five to Giant Three” [4]

Суть тенденции такова. В 1995-1996 годах лидерами на рынке реляционных СУБД были DB2, Informix, Microsoft SQL Server, Oracle, Sybase, что давало основание говорить о большой пятерке СУБД и определило название “Big Five” (большая пятерка) данной лидирующей группы продуктов, и, соответственно, их поставщиков. Таковой ситуация была в 1996 году.

К 2001 году ситуация стала совершенно иной. Качественное представление о ней дают так называемые “магические квадраты”, предложенные компанией Gartner Group для оценки положения той или иной IT-компании на рынке информационных технологий (см. Рис.1).

 

Рис.1. Магические квадраты Gartner Group

Согласно анализу Gartner Group, лидирующую группу составляют три компании: IBM, Microsoft, Oracle. При этом IBM и Oracle находятся в квадрате “Лидеры”, Microsoft рассматривается пока только как исследователь. Выявленная тенденция лидерства трех компаний с все более увеличивающимся разрывом с конкурентами будет сохранена. Другие СУБД (Sybase, Adabas и т.д.) находятся в квадрате “Нишевые игроки” и никогда уже не выйдут на широкий рынок.

Наиболее существенным критерием для сравнения СУБД являются эксплуатационные характеристики, такие как надежность, высокая готовность, производительность, масштабируемость. В отчете компании Gartner Group “Strategic Data Management Scenario” приводится сравнительный анализ основных СУБД по этим показателям (см. табл.1), выполненный на основе экспертных оценок. Каждому показателю была дана оценка по 10-бальной шкале, максимальная оценка 10 баллов.

 

Табл.1.

СУБД	Производительность	Конкурентный доступ	По числу пользователей	Поддержка больших БД	Готовность
CA-OpenIngres	7	8	6	5	6
IBM DB2 UDB	7	8	6	6	6
Informix Dynamic Server	8	8	7	8	7
Microsoft SQL Server	6	7	5	5	7
Oracle8	8	9	8	8	8
Sybase Adaptive Server	7	7	7	6	6
IBM DB2 OS/390	9	8	9	9	9

 

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

 

2.2. IBM DB2

 

Система СУБД DB2 – один из “долгожителей” в мире систем управления базами данных. Имея в своей основе классическую реляционную модель данных, система первоначально разрабатывалась для больших ЭВМ. Только впоследствии компания IBM реализовала DB2 для платформы AS/400 (СУБД получила название DB2/400), а несколько позже приступила к выпуску практически нового продукта под названием Universal Data Base (UDB), который, как предполагалось, будет соответствовать стандартам открытых систем и функционировать на широком спектре платформ, включая Unix и Windows.

В настоящий момент позиции СУБД DB2 исключительно сильны в первую очередь на больших ЭВМ. Если сравнить экспертные оценки по эксплуатационным характеристикам, приведенные в таблице 1, то видно, что СУБД DB2 обладает практически наивысшими оценками именно на платформе больших ЭВМ. Показательно и то, что СУБД UDB рассматривается в таблице отдельно. Это как раз показатель того, что под общим брэндом DB2 скрывается три практически различных продукта – DB2 для больших ЭВМ, DB2/400 и универсальная DB2 для других платформ. В контексте современной технической политики, которая требует безусловной и максимально возможной унификации базового программного обеспечения, наличие трех различных программных продуктов является негативным фактором.   

Являясь главным конкурентом СУБД Oracle в Северной Америке, на российском рынке СУБД DB2, несмотря на высокое техническое качество продукта, представлена очень слабо. Возможно, это связано с общей стратегией компании IBM на российском рынке, когда основной акцент сделан на поставках компьютерных платформ. Фактом является то, что в России с DB2 работают лишь группы энтузиастов. Практически нет инфраструктуры, необходимой для широкого распространения продукта, нет достаточного числа обученных специалистов, нет широкой сети учебных центров, отсутствует литература на русском языке. Представительство IBM в России практически не имеет отделения по технической поддержке DB2, что существенно осложняет эксплуатацию СУБД. Инсталляционная база DB2 в России очень ограничена и затрагивает по большей части большие ЭВМ и AS/400. Партнерская сеть IBM по DB2 невелика по сравнению, скажем, с Microsoft или Oracle. DB2 пока не удалось стать стандартом баз данных для платформ UNIX (здесь эта ниша занята Oracle) и Windows NT (ниша занята Microsoft SQL Server и Oracle).

 

2.3. СУБД Oracle.

2.3.1 Общая характеристика.

СУБД Oracle – ветеран рынка реляционных СУБД. Разработка этой системы была начата практически в то же время, что и IBM DB2 и по настоящее время эти системы остаются основными конкурентами (что видно из рисунка 1).

Oracle занимает лидирующие позиции на рынке СУБД и, что особенно важно, лидирует на платформах Unix и Windows. В России также обозначилось лидерство Oracle, особенно в области крупномасштабных информационных систем. Фактически в нашей стране СУБД Oracle стала стандартом государственных информационных систем [5].

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

Служба технической поддержки Oracle построена на профессиональной основе. Служба технической поддержки в России сертифицирована по стандарту ISO 9000.

Кроме того, ведущие компании – партнеры Oracle, такие как FORS, RDTex имеют собственные центры технической поддержки.

Важным является и то, что наряду с СУБД, компания Oracle поставляет центральный инфраструктурный продукт – Internet Application Server, сервер приложений, функционирующих в среде Internet/Intranet, а также CASE-средства, средства быстрой разработки приложений, средства построения хранилищ данных, оперативного анализа данных, выявления сложных зависимостей в данных (Data Mining), что позволяет поставлять не отдельные продукты, но комплексные технологические решения для заказчиков.

2.3.2 Поддержка большинства платформ.

С технической точки зрения важно то, что Oracle функционирует практически на всех существующих компьютерных платформах, в том числе и на больших ЭВМ (OS/390) и на еще сохраняющих популярность системах Vax VMS, не говоря уже о Windows NT и различных разновидностях Unix, в том числе Solaris, HP-UX, AIX, Linux, SCO Unix и т.д.

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

Ядром СУБД Oracle является сервер базы данных, который поставляется в одном из четырех вариантов в зависимости от масштаба информационной системы, в рамках которой предполагается его применение. Для систем масштаба крупной организации предлагается продукт Oracle Database Enterprise Edition (корпоративная редакция) [6], для которого имеется целый набор опций, архитектурно и функционально расширяющих возможности сервера. Именно Oracle Database Enterprise Edition устанавливается на кластерах (с опцией Parallel Server, по версию 8i включительно или RAC – Real Application Cluster, начиная с версии 9i и старше), позволяя создавать системы высокой готовности. Продукт Oracle Database Standard Edition (стандартная редакция) [6] ориентирован на организации среднего масштаба или подразделения в составе крупной организации. Для персонального использования предназначен продукт Oracle Database Personal Edition (персональная редакция) [6].

Важнейшим преимуществом Oracle перед конкурентами (и, прежде всего, перед DB2) является идентичность кода различных версий сервера баз данных Oracle для всех платформ, гарантирующая идентичность и предсказуемость работы Oracle на всех типах компьютеров, какие бы не входили в ее состав. Все варианты сервера Oracle имеют в своей основе один и тот же исходный программный код и функционально идентичны, за исключением некоторых опций, которые, например, могут быть добавлены к Oracle Database Enterprise Edition и не могут - к Oracle Database Standard Edition.

Таким образом, для всех платформ существует единая СУБД в различных версиях, которая ведет себя одинаково и предоставляет одинаковую функциональность вне зависимости от платформы, на которой она установлена. Разработку серверных продуктов в составе СУБД выполняет единое подразделение корпорации Oracle, изменения вносятся централизовано, после этого подвергаются тщательному тестированию в базовом варианте, а затем переносятся на все платформы, где также детально проверяются. Возможность переноса Oracle обеспечивается специфической структурой исходного программного кода сервера. Приблизительно 80% программного кода Oracle – это программы на языке программирования C, который (с известными ограничениями) является платформо - независимым. Примерно 20% кода, представляющее собой ядро сервера, реализовано на машинно-зависимых языках и эта часть кода, разумеется, переписывается для различных платформ.

Жесткая технологическая схема разработки Oracle, опирающаяся на принципы идентичности исходного программного кода для различных версий и платформ,  контрастирует со схемами других компаний. Так, СУБД DB/2 представляет собой семейство продуктов, но не единый продукт. Функционально версия DB2 для IBM S/390 столь существенно отличается от DB2 для платформ UNIX и NT, что позволяет говорить вообще о разных продуктах.

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

 

3. Заключение

 

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

 

 

Литература

 

1.      Зеленков Ю.А. «Введение в базы данных». Учебный курс. http://www.mstu.edu.ru/education/materials/zelenkov/toc.html

2.      Bachman C. W. The Programmer as Navigator, CACM 16.11, Nov. 1973.

3.      Журнал «СУБД» № 1, 1995. Реляционная модель данных для больших совместно используемых банков данных. http://www.osp.ru/dbms/1995/01/01.htm

4.      New Data Management Markets. Gartner Group, August 1999

5.      Интернет сайт Oracle corporation. http://www.oracle9i.ru/partnerinfo/select_stories.phtml

6.      Интернет сайт Oracle corporation. http://www.oracle.com/global/ru/ip/10g/database/index.html