Выбор СУБД для построения информационных систем

3.5.3.4. Реляционная алгебра

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

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

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

По поводу теоретико-множественных  операций реляционной алгебры следует  еще заметить, что все четыре операции являются ассоциативными. Т. е., если обозначить через OP любую из четырех операций, то (A OP B) OP C = A (B OP C), и следовательно, без введения двусмысленности можно писать A OP B OP C (A, B и C - отношения, обладающие свойствами, требуемыми для корректного выполнения соответствующей операции). Все операции, кроме взятия разности, являются коммутативными, т.е. A OP B = B OP A.

Специальные реляционные операции включают:

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

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

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

3.5.3.5. Реляционное исчисление

Предположим, что мы работаем с  базой данных, обладающей схемой СОТРУДНИКИ (СОТР_НОМ, СОТР_ИМЯ, СОТР_ЗАРП, ОТД_НОМ) и ОТДЕЛЫ (ОТД_НОМ, ОТД_КОЛ, ОТД_НАЧ), и хотим узнать имена и номера сотрудников, являющихся начальниками отделов с количеством сотрудников больше 50.

Если бы для формулировки такого запроса использовалась реляционная алгебра, то мы получили бы алгебраическое выражение, которое читалось бы, например, следующим образом:

• выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫ по условию СОТР_НОМ = ОТД_НАЧ;
• ограничить полученное отношение по условию ОТД_КОЛ > 50;
• спроецировать результат предыдущей операции на атрибут СОТР_ИМЯ, СОТР_НОМ.

Мы четко сформулировали последовательность шагов выполнения запроса, каждый из которых соответствует одной  реляционной операции. Если же сформулировать тот же запрос с использованием реляционного исчисления, которому посвящается этот раздел, то мы получили бы формулу, которую можно было бы прочитать, например, следующим образом: Выдать СОТР_ИМЯ и СОТР_НОМ для сотрудников таких, что существует отдел с таким же значением ОТД_НАЧ и значением ОТД_КОЛ большим 50.

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

 

3.6. Будущее развитие БД

 

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

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

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

 

 

 

 

 

 

 

 

 

 

3.7. Критерии сравнения СУБД. Методология  выбора

 

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

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

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

• Моделирование данных
• Особенности архитектуры и функциональные возможности
• Контроль работы системы
• Особенности разработки приложений
• Производительность
• Надежность
• Требования к рабочей среде
• Смешанные критерии

Рассмотрим каждую из этих групп  в отдельности.

 

Моделирование данных.

• Используемая модель данных. Существует множество моделей данных; самые распространенные: иерархическая, сетевая, реляционная, объектно-реляционная и объектная. Вопрос об использовании той или иной модели должен решаться на начальном этапе проектирования информационной системы.
• Триггеры и хранимые процедуры. Триггер - программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура – программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и хранимых процедур используются различные инструменты.
• Средства поиска. Некоторые современные системы имеют встроенные дополнительные средства контекстного поиска.
• Предусмотренные типы данных. Здесь следует учесть два фактически независимых критерия: базовые или основные типы данных, заложенные в систему, и наличие возможности расширения типов. В то время, как отклонения базовых наборов типов данных у современных систем от некоего стандартного, обычно, не велики, механизмы расширения типов данных в системах того или иного производителя существенно различаются.
• Реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют те или иные расширения данного стандарта.

 

Особенности архитектуры и функциональные возможности.

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

Контроль работы системы

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

 

Особенности разработки приложений.

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

• Средства проектирования. Некоторые системы имеют средства автоматического проектирования, как баз данных, так и прикладных программ. Средства проектирования различных производителей могут существенно различаться.
• Многоязыковая поддержка. Поддержка большого количества национальных языков расширяет область применения системы и приложений, построенных на ее основе.
• Возможности разработки Web-приложений. При разработке различных приложений зачастую возникает необходимость использовать возможности среды Internet. Средства разработки некоторых производителей имеют большой набор инструментов для построения приложений под Web.
• Поддерживаемые языки программирования. Широкий спектр используемых языков программирования повышает доступность системы для разработчиков, а также может существенно повлиять на быстродействие и функциональность создаваемых приложений.

 

 

Производительность.

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