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

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

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

Суть реляционной СУБД можно пояснить на следующем простом примере (рис. 4).

Рис. 4 Простой пример, иллюстрирующий принцип реляционной модели

В некоторой реляционной БД (РБД) имеются два файла авторов и публикаций, каждый из которых содержит определенное число записей/ состоящих из фиксированного числа полей (соответственно 4 и 5), представляющих данные по соответствующим элементам предметной области (рис. 4). Можно сказать, что определены два отношения (фaйла), имеющие общий элемент — значения поля № п/п. Операции реляциан ной алгебры могут объединять два типа записей по этому общему элементу. Например, в результате соединения запись Бухтяк может представится в следующем виде:

Бухтяк<Томск><637-2050><40><Основы...><статья><2.95><2.5>....

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

Реляционная СУБД должна четко отслеживать взаимосвязи записей в БД во избежание потери или искажения информации. С этой целью СУБД постоянно пересчитывает число связей для каждой записи БД в прямом и обратном направлениях, что требует существенных временных затрат для больших БД. Простота и стройность реляционной алгебры делают ее весьма привлекательной для организации реляционных БД, что мы и видим, прежде всего, для класса ПК. Однако в действительности реальные данные предметной области не укладываются в указанную модель (например, отношения могут содержать повторяющиеся записи и т.д.). Поэтому наряду с сугубо реляционными существуют и другие даталогические модели СУБД и их различные модификации и сочетания, обеспечивая широкий круг решаемых на их основе информационных, коммерческих, управленческих, финансовых, вычислительных и других типов задач. Из наиболее известных примеров реляционных СУБД можно отметить такие, как: dBase, DB/2, ORACLE, Paradox и ряд других.

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

— массовое использование ПК в приложениях, предопределяющих работу с БД;

— резкое уменьшение цикла разработки ПС из-за персонального характера работы;

— наличие достаточно развитых системных и инструментальных средств;

— наличие внешней памяти большой емкости на "винчестерах".

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

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

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

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

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

Объектно-ориентированные СУБД (ООСУБД)

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

Характеристики ООСУБД подразделяются на три определяющие группы:

— базовые, определяющие принадлежность СУБД к объектно-ориентированному классу;

— по выбору, позволяющие улучшать ООСУБД, но не являющиеся базовыми;

— открытости, позволяющие пользователю делать осознанный выбор из ряда одинаково приемлемых реализаций ООСУБД.

В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД в ее классическом понимании и быть объектно-ориентированной системой (ООС), т.е. в определенной степени она должна быть совместимой с современными объектно-ориентированными ЯВУ. Первый критерий включает следующие пять характеристик, присущих классической СУБД: сохранность данных, развитое управление внешней памятью, возможность совмещения обработки и поиска данных, поддержка средств восстановления и возможность быстрого доступа к БД по запросу пользователя. Отмеченные характеристики в той или иной мере обсуждались выше. Второй критерий предполагает наличие следующих характеристик, присущих собственно объектно - ориентированной технологии: понятие сложных объектов, идентичность объектов, инкапсуляция, типы или классы, наследование, настройка (сочетающаяся с отложенным присвоением), расширяемость и вычислительная полнота. Характеристики первого критерия хорошо известны пользователям традиционных СУБД (dBase, R-Base, др.)

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

Объектные конструкторы должны удовлетворять принципу ортогональности: любой конструктор может применяться к любому объекту. Например, конструкторы РБД не обладают данным свойством (так конструктор множества может применяться только к кортежам, а конструктор кортежей — только к первичным типам).

Глава 4

Иерархические стpуктуpы

Дерево представляет собой иерархию элементов, называемую узлами. На самом верхнем уровне иерархии имеется только один узел - корень. Каждый узел, кроме корня, связан с одним узлом на более высоком уровне, называемым исходным узлом для данного узла. Ни один элемент не имеет более одного исходного. Каждый элемент может быть связан с одним или нескольким элементами на более низком уровне. Они называются порожденными. Иерархические структуры относительно просто создаются и поддерживаются. Это важно для ряда приложений, однако множество данных по своей природе не связаны в древовидные структуры. Во многих структурах данных одна запись требует более одного представления (поэтому приходится разрабатывать способы объединения данных, которые по разному представляются различным пользователям, в одну общую схему БД. В результате получаются обычно более сложные структуры по сравнению с древовидными. Поэтому программное обеспечение, сконструированное только для работы с древовидными структурами, имеет ограниченное применение и не редко сильно влияет на возможности увеличения объема и развития БД.

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

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