Главная
Коллекция "Otherreferats"
Программирование, компьютеры и кибернетика
Выбор СУБД для построения информационных систем
Выбор СУБД для построения информационных систем
Выбор системы управления базами данных (СУБД) при построении информационных систем. Специфика информационных программных систем. Общая классификация архитектур приложений. Файловые системы и функции СУБД, критерии их сравнения и методология выбора.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 12.02.2012 |
| Размер файла | 245,3 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
b. Все ранние системы не основывались на каких-либо абстрактных моделях. Как мы упоминали, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
c. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
d. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
e. После появления реляционных систем большинство ранних систем было оснащено "реляционными" интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.
3.4.1 Иерархические системы
Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом как на новую технологию БД, так и на новую технику.
1. Иерархические структуры данных. Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного "корневого" типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи.
Рис.3.1 Пример типа дерева (схемы иерархической БД) [3]
Здесь “Отдел” является предком для “Начальник” и “Сотрудники”, а “Начальник” и “Сотрудники" - потомки “Отдел”. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (мы показываем один экземпляр дерева):
Рис.3.2 Пример схемы базы данных [3]
Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. Для БД определен полный порядок обхода - сверху вниз, слева направо.
2. Манипулирование данными. Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие:
· Найти указанное дерево БД (например, отдел 310);
· Перейти от одного дерева к другому;
· Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);
· Перейти от одной записи к другой в порядке обхода иерархии;
· Вставить новую запись в указанную позицию;
· Удалить текущую запись.
3. Ограничения целостности. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя. Заметим, что аналогичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается (примером такой "внешней" ссылки может быть содержимое поля “Каф_Номер” в экземпляре типа записи “Куратор”).
В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии. Примером представления приведенной выше БД может быть иерархия, показанная на рисунке 3.3.
Рис.3.3 Примером представления БД [3]
3.4.2 Сетевые системы
Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.
1. Сетевые структуры данных. Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи.
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:
· Каждый экземпляр типа P является предком только в одном экземпляре L;
· Каждый экземпляр C является потомком не более, чем в одном экземпляре L.
На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:
a. Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).
b. Данный тип записи P может быть типом записи предка в любом числе типов связи.
c. Данный тип записи P может быть типом записи потомка в любом числе типов связи.
d. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка. Если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.
e. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.
f. Предок и потомок могут быть одного типа записи.
g.
Рис.3.4 Простой пример сетевой схемы БД [3].
2. Манипулирование данными. Примерный набор операций может быть следующим:
Найти конкретную запись в наборе однотипных записей (инженера Сидорова);
· Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);
· Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);
· Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);
· Создать новую запись;
· Уничтожить запись;
· Модифицировать запись;
· Включить в связь;
· Исключить из связи;
· Переставить в другую связь и т.д.
3. Ограничения целостности. В принципе их поддержание не требуется, но иногда требуют целостности по ссылкам (как в иерархической модели).
3.4.3 Достоинства и недостатки ранних СУБД
Сильные места ранних СУБД:
· Развитые средства управления данными во внешней памяти на низком уровне;
· Возможность построения вручную эффективных прикладных систем;
· Возможность экономии памяти за счет разделения подобъектов (в сетевых системах).
Недостатки:
· Слишком сложно пользоваться;
· Фактически, необходимы знания о физической организации;
· Прикладные системы зависят от этой организации;
· Их логика перегружена деталями организации доступа к БД.
3.5 Реляционный подход к СУБД
3.5.1 Основные понятия
Перейдем теперь к рассмотрению реляционного подхода к организации баз данных.
Обсудим сначала основные понятия реляционных баз данных - это тип данных, домен, атрибут, кортеж, первичный ключ и отношение [2].
Тип данных. Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем дополнительными типами данных (соответствующими возможностями обладают многие современные системы).
Домен. Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена.
Другими словами, домен - множество значений данного типа. Например, домен атрибута "Имена" определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака). Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. Например, значения доменов "Номера телефонов" и "Возраст" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена или не используется, или используется лишь частично.
Схема отношения, схема базы данных. Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается) }. Степень или "арность" схемы отношения - мощность этого множества. Схема БД (в структурном смысле) - это набор именованных схем отношений.
Кортеж. Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.
Отношение - это множество кортежей, соответствующих одной схеме отношения. Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют ясную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.
3.5.2 Фундаментальные свойства отношений
Остановимся теперь на некоторых важных свойствах отношений, которые следуют из приведенных ранее определений:
Отсутствие кортежей-дубликатов. Про отношение, обладающее таким свойством, говорят, что оно нормализовано. Из этого свойства вытекает наличие у каждого нормализованного отношения так называемого первичного ключа - набора атрибутов, значения которых однозначно определяют кортеж отношения. Для каждого отношения, по крайней мере, полный набор его атрибутов обладает этим свойством. Однако при формальном определении первичного ключа требуется обеспечение его "минимальности", т.е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства - однозначно определять кортеж. Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных.
Отсутствие упорядоченности кортежей. Свойство отсутствия упорядоченности кортежей отношения также является следствием определения отношения-экземпляра как неупорядоченного множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список кортежей.
Отсутствие упорядоченности атрибутов. Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной форме определения схемы отношения.
Атомарность значений атрибутов. Значения всех атрибутов являются атомарными (неделимыми). Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения). Принято говорить, что в реляционных базах данных допускаются только нормализованные отношения или отношения, представленные в первой нормальной форме.
3.5.3 Реляционная модель данных
3.5.3.1 Общая характеристика
Наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах. Согласно Дейту [1] реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.
3.5.3.2 Целостность сущности и ссылок
В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом.
Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений.
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Если мы вернемся к примеру информационной системы отдела кадров, то это означает, что если для сотрудника указан номер отдела, то этот отдел должен существовать.
Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. С целостностью по ссылкам дела обстоят несколько более сложно.
Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа из отношения, на которое ведет ссылка?
Здесь существуют три подхода, каждый из которых поддерживает целостность по ссылкам. Первый подход заключается в том, что запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа). При втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным. Наконец, третий подход (каскадное удаление) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по ссылкам для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.
3.5.3.3 Базисные средства манипулирования реляционными данными
Рассмотрим более подробно манипуляционную часть реляционной модели данных. Как мы видели выше, в манипуляционной составляющей определяются два базовых механизма манипулирования реляционными данными - основанная на теории множеств реляционная алгебра и базирующееся на математической логике (точнее, на исчислении предикатов первого порядка) реляционное исчисление.
Все эти механизмы обладают одним важным свойством: они замкнуты относительно понятия отношения. Это означает, что выражения реляционной алгебры и формулы реляционного исчисления определяются над отношениями реляционных БД и результатом вычисления также являются отношения. В результате любое выражение или формула могут интерпретироваться как отношения, что позволяет использовать их в других выражениях или формулах.
Как мы увидим, алгебра и исчисление обладают большой выразительной мощностью: очень сложные запросы к базе данных могут быть выражены с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления. Именно по этой причине именно эти механизмы включены в реляционную модель данных. Конкретный язык манипулирования реляционными БД называется реляционно-полным, если любой запрос, выражаемый с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления, может быть выражен с помощью одного оператора этого языка.
Механизмы реляционной алгебры и реляционного исчисления эквивалентны, т.е. для любого допустимого выражения реляционной алгебры можно построить эквивалентную (т.е. производящую такой же результат) формулу реляционного исчисления и наоборот. Отличие состоит в уровне процедурности. Выражения реляционной алгебры строятся на основе алгебраических операций (высокого уровня), и подобно тому, как интерпретируются арифметические и логические выражения, выражение реляционной алгебры также имеет процедурную интерпретацию. Другими словами, запрос, представленный на языке реляционной алгебры, может быть вычислен на основе вычисления элементарных алгебраических операций с учетом их старшинства и возможного наличия скобок. Для формулы реляционного исчисления однозначная интерпретация, вообще говоря, отсутствует. Формула только ставит условия, которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления являются более непроцедурными или декларативными.
Поскольку механизмы реляционной алгебры и реляционного исчисления эквивалентны, то в конкретной ситуации для проверки степени реляционности некоторого языка БД можно пользоваться любым из этих механизмов.
Заметим, что крайне редко алгебра или исчисление принимаются в качестве полной основы какого-либо языка БД. Обычно (как, например, в случае языка SQL) язык основывается на некоторой смеси алгебраических и логических конструкций. Тем не менее, знание алгебраических и логических основ языков баз данных часто бывает полезно на практике.
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 - это отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы.
· Возможности параллельной архитектуры. Для обеспечения параллельной обработки данных существует, как минимум, два подхода: распараллеливание обработки последовательности запросов на несколько процессоров, либо использование нескольких компьютеров-клиентов, работающих с одной БД, которые объединяют в так называемый параллельный сервер.
· Возможности оптимизирования запросов. При использовании непроцедурных языков запросов, выполнение этих запросов может быть очень неоптимальным. Поэтому необходимо произвести процесс оптимизации запросов, т.е. выбрать такой способ выполнения запросов, когда по начальному представлению запроса путем его синтаксических и семантических преобразований вырабатывается процедурный план выполнения запроса, наиболее оптимальный при существующих в базе данных управляющих структурах.
Надежность.
Понятие надежности системы имеет много смыслов - это и сохранность информации независящая от любых сбоев, и безотказность работы системы в любых условиях, и обеспечение защиты данных от несанкционированного доступа.
· Восстановление после сбоев. При возникновении программных или аппаратных сбоев целостность, да и работоспособность всей системы может быть нарушена. От того, как эффективно спланирован механизм восстановления после сбоев, зависит жизнеспособность системы.
· Резервное копирование. В результате аппаратного сбоя может быть частично поврежден или выведен из строя носитель информации и тогда восстановление данных невозможно, если не было предусмотрено резервное копирование базы данных, или ее части. Резервное копирование спасает и в ситуациях, когда происходит логический сбой системы, например при ошибочном удалении таблиц. Существует множество механизмов резервирования данных (хранение одной или более копий всей базы данных, хранение копии ее части, копирование логической структуры и т.д.). Зачастую в систему закладывается возможность использования нескольких таких механизмов.
· Откат изменений. При выполнении транзакции применяется простое правило - либо транзакция выполняется полностью, либо не выполняется вообще. Это означает, что в случае сбоев, все результаты недоведенных до конца транзакций должны быть аннулированы. Механизм отката может иметь различное быстродействие и эффективность.
· Многоуровневая система защиты. Информационная система организации почти всегда включает в себя секретную информацию, поэтому для предотвращения несанкционированного доступа используется служба идентификации пользователей. Уровень защиты может быть различным. Кроме непосредственной идентификации пользователей при входе в систему может использоваться также механизм шифрования данных при передаче по линиям связи.
Требования к рабочей среде.
· Поддерживаемые аппаратные платформы.
· Минимальные требования к оборудованию.
· Максимальный размер адресуемой памяти. Поскольку почти все современные системы используют свою файловую систему, немаловажным фактором является то, какой максимальный объем физической памяти они могут использовать.
· Операционные системы, под управлением которых способна работать СУБД.
Смешанные критерии.
· Качество и полнота документации. К сожалению, не все системы имеют полную и подробную документацию.
· Локализованность. Возможность использования национальных языков не во всех системах реализована полностью.
· Модель формирования стоимости. Как правило, производители СУБД используют определенные модели формирования стоимости. Например, стоимость одного и того же продукта может существенно изменяться в зависимости от того, сколько пользователей будет с ним работать.
· Стабильность производителя.
· Распространенность СУБД.
Этот перечень, безусловно, не является полным и не претендует на жесткую классификацию требований, предъявляемых к СУБД каждой конкретной информационной системой. В каком-то случае может оказаться, что часть из них просто не являются важными. В другом окажется, что существуют и другие, не перечисленные здесь критерии, и именно они определят выбор СУБД.
4. Заключение
Итак, мы выделили несколько архитектур построения информационных систем: файл-сервер, клиент-сервер, Intranet, и хранилища данных. В каждой из них, по сути, можно выделить как клиентскую, так и серверную части, различие состоит только в том, что делают клиент и сервер.
В среде файлового сервера обработка данных распределена в сети, обычно представляющей собой локальную вычислительную сеть (ЛВС). Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако, пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлам. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файл-сервера. Такой подход характеризуется значительным сетевым трафиком, что может привести к снижению производительности всей системы в целом. Кроме того, на каждой рабочей станции должна находиться полная копия СУБД; и, поскольку доступ к одним и тем же файлам может осуществляться сразу несколькими копиями СУБД, управление параллельностью, восстановлением и целостностью усложняется.
Таким образом, на основе файл-серверной архитектуры имеет смысл строить простые, работающие с небольшими объемами информации и рассчитанные на применение в однопользовательском режиме приложения (например, бухгалтерские и складские программы), тем более, что файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Однако, в более сложных случаях файл-серверные архитектуры становятся недостаточными. Для построения файл-серверных информационных систем используют небольшие локальные СУБД, например Access, компании Microsoft.
Технология клиент-сервер была разработана с целью устранения недостатков, имеющихся в файл-серверном подходе. Клиент управляет пользовательским интерфейсом и логикой приложения, действуя, как сложная рабочая станция, на которой выполняются приложения баз данных. Клиент принимает от пользователя запрос, проверяет синтаксис и генерирует запрос к базе данных на языке SQL или другом языке базы данных, который соответствует логике приложения. Затем он передает сообщение серверу, ожидает поступления ответа и форматирует полученные данные для представления их пользователю. Сервер принимает и обрабатывает запросы к базе данных, а затем передает полученные данные обратно клиенту. Такая обработка включает проверку полномочий клиента, обеспечение требований целостности, поддержку системного каталога, а также выполнение запроса и обновление данных. Помимо этого, поддерживается управление параллельностью и восстановлением.
Архитектура "клиент-сервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файл-сервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию, поскольку увеличение масштабов информационной системы не порождает принципиальных проблем. Кроме того, сокращаются коммуникационные расходы, и повышается уровень непротиворечивости данных, так как все ограничения определяются и проверяются только в одном месте.
Архитектура Intranet-приложений является, по сути, продолжением архитектуры клиент - сервер, используя среду Internet. Web-среда представляет собой очень привлекательную платформу для разработки и распространения информационных приложений. Благодаря повсеместному использованию Web-технологий, созданные для этой среды приложения обладают глобальной доступностью для пользователей и организаций. Поскольку Web-архитектура была разработана как платформенно-независимая, она обладает значительным потенциалом в отношении существенного сокращения расходов на развертывание приложений и обучение персонала. Большое количество мощных и удобных средств разработки Web-приложений позволяет быстро и эффективно создавать клиентскую часть системы. На этой архитектуре строятся все более распространяющиеся Internet-магазины, системы заказа билетов и т.д.
К недостаткам данной архитектуры относятся недостаточная надежность Internet, как коммуникационной среды и низкий уровень защищенности информации.
Как мы уже говорили, системы управления базами данных насквозь пронизывают всю промышленность, причем доминирующим типом систем являются реляционные СУБД. Эти системы проектировались для управления большим потоком транзакций, каждая из которых сопровождалась внесением незначительных изменений в оперативные данные предприятия - т.е. в данные, которые предприятие обрабатывало в процессе своей повседневной деятельности. Системы подобного типа называются системами оперативной обработки транзакций, или OLTP-системами (Online Transaction Processing).
В то же время лицам, ответственным за принятие корпоративных решений, необходимо иметь доступ ко всем данным организации независимо от их расположения. Для выполнения полного анализа деятельности организации, определения ее бизнес показателей, выяснения характеристик существующего спроса и тенденций его изменения необходимо иметь доступ не только к текущим, но и к ранее накопленным данным. Для упрощения подобного анализа была разработана концепция хранилища данных. Предполагается, что такое хранилище содержит сведения, поступающие из самых разных источников данных, а также различные накопительные и сводные данные. Концепция хранилища данных базируется на усовершенствованной технологии баз данных и предусматривает специальные средства управления процессом хранения информации. Для анализа накопленных данных применяют мощные инструменты оперативной аналитической обработки данных - OLAP (Online Analitical Processing).
Таким образом, мы можем выделить специфические характеристики хранилищ данных. В отличие от OLTP-систем, хранилища данных содержат статические данные, имеют низкую интенсивность обработки транзакций, да и число пользователей такой системы ограничено. Способ использования данных является совершенно непредсказуемым, поэтому и способ обработки данных носит деструктурируемый, скорее, эвристический характер. Вообще говоря, подход хранилищ данных еще слишком молод, чтобы вокруг него сложился круг общепринятых понятий, терминов, технологических приемов. Тем не менее, он кажется настолько важным и перспективным, что многие компании (в том числе и ведущие производители СУБД) ведут активную работу, чтобы быть в авангарде этого направления.
После того, как выбрана архитектура построения информационной системы и определены основные требования, которые система предъявляет к СУБД, необходимо определиться с выбором конкретного продукта. И если в случае файловых систем этот выбор достаточно прост (на рынке представлен небольшой диапазон локальных систем), то для остальных типов информационных систем этот выбор становится нетривиальным. Даже при поверхностном анализе рынка СУБД мы можем увидеть такой богатый спектр продукции, что остановиться на чем-то конкретном очень трудно. Здесь приходится применять более подробный анализ каждой конкретной системы и смотреть, насколько СУБД удовлетворяет выработанным критериям.
К сожалению, если просто отмечать, насколько хороши или плохи те или иные параметры в случае каждой конкретной СУБД, то сравнение даже двух различных систем может оказаться очень трудной задачей. Хотя, четкий и глубокий сравнительный анализ на основании конкретных критериев в любом случае поможет выбрать вам наиболее подходящую для конкретного проекта систему, и затраченные усилия в любом случае не окажутся напрасными.
На практике, как правило, решение об использовании той, или иной СУБД принимает один человек - обычно, руководитель предприятия, а он может опираться отнюдь не на технические критерии. Здесь свою роль могут сыграть такие, с технической точки зрения незначительные факторы, как рекламная раскрутка компании-производителя СУБД, использование конкретных систем на других предприятиях, стоимость. Причем, последний фактор можно понимать в двух смыслах, в зависимости от финансового состояния и политики предприятия. С одной стороны, это может быть принцип - чем дороже, тем лучше; с другой, наоборот - возможность бесплатного использования продукта (в случае выбора коммерческой системы - возможность “взлома" лицензионной защиты программного продукта). Ясно, что такой подход не может способствовать долгосрочному использованию системы и развитию компании.
5. Словарь терминов
Intranet - Web-сайт или группа web-сайтов, принадлежащих одной организации и доступных только членам этой организации.
OLAP (Online Analytical Processing) - Оперативный анализ данных. Этот метод обработки применяется с целью ускорения обработки запросов и предусматривает предварительный расчет часто запрашиваемых данных (например, сумм или значений счетчика).
OLTP (Online Transaction Processing) - системами оперативной обработки транзакций.
SQL (Structured Query Language) - Язык структурированных запросов, язык S0L. Является принятым в отрасли стандартом для выполнения операций вставки, обновления, удаления и выборки данных из реляционных БД.
Апплет - Web-программа, передаваемая клиенту сервером и выполняемая на клиенте.
Атрибут - Поименованный столбец отношения.
База данных - Совместно используемый набор логически связанных данных (и описание этих данных), предназначенный для удовлетворения информационных потребностей организации.
Браузер - программа, позволяющая просматривать документы в стандарте HTML.
Внешний ключ - Атрибут или множество атрибутов внутри отношения, которое соответствует потенциальному ключу некоторого (может быть того же самого) отношения.
Домен - Набор допустимых значений атрибута.
Индекс - Механизмы быстрого доступа к хранящимся в таблицах данных путем их предварительной сортировки.
Интероперабельность - Возможность упрощения комплексирования новых программных систем на основе использования готовых компонентов со стандартными интерфейсами.
Кардинальность - Количество кортежей отношения.
Кортеж - Строка отношения.
Локальные БД - БД, располагающаяся на одном компьютере.
Масштабируемость - Гибкость системы по отношению к числу одновременно работающих пользователей.
Мобильность - Сравнительная простота переноса программной системы в широком спектре аппаратно-программных средств, соответствующих стандартам.
Модель данных - Интегрируемый набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в некоторой организации.
Нормализованное отношение - отношение, в котором отсутствуют повторяющиеся группы данных.
Отношение - Плоская таблица, состоящая из столбцов и строк.
Первичный ключ - Потенциальный ключ, который выбран для уникальной идентификации кортежей внутри отношения.
Потенциальный ключ - Суперключ, который не содержит подмножества, так же являющегося суперключом данного отношения.
Распределенные БД - БД, располагающаяся на нескольких компьютерах.
Степень отношения - Количество атрибутов отношения.
СУБД - это программные средства для создания, наполнения, обновления и удаления баз данных.
Суперключ (superkey) - Атрибут или множество атрибутов, которое единственным образом идентифицирует кортеж данного отношения.
Сущность - Отдельный тип объекта организации (человек, место или вещь, понятие или событие), который нужно представить в базе данных.
Подобные документы
Основные понятия базы данных и систем управления базами данных. Типы данных, с которыми работают базы Microsoft Access. Классификация СУБД и их основные характеристики. Постреляционные базы данных. Тенденции в мире современных информационных систем.
курсовая работа [46,7 K], добавлен 28.01.2014Общее понятие и признаки классификации информационных систем. Типы архитектур построения информационных систем. Основные компоненты и свойства базы данных. Основные отличия файловых систем и систем баз данных. Архитектура клиент-сервер и ее пользователи.
презентация [203,1 K], добавлен 22.01.2016Термины "логический" и "физический" как отражение различия аспектов представления данных. Методы доступа к записям в файлах. Структура систем управления базами данных. Отличительные особенности обработки данных, характерные для файловых систем и СУБД.
лекция [169,7 K], добавлен 19.08.2013Основные направления в истории развития компьютерной индустрии. Специфика информационных программных систем. Основные задачи информационных систем. Классификация архитектур информационных приложений. Файл-серверные и клиент-серверные приложения.
презентация [110,8 K], добавлен 11.04.2013Архитектура "клиент-сервер". Параллельная обработка данных в многопроцессорных системах. Модернизация устаревших информационных систем. Характерные черты современных серверных СУБД. Наиболее популярные серверные СУБД. Распределенные запросы и транзакции.
курсовая работа [309,2 K], добавлен 11.11.2011Создание автоматизированных систем управления для предприятий нефтяной и газовой промышленности. Система управления базами данных (СУБД), ее функциональные возможности, уровневая архитектура. Характеристика реляционных, объектных и распределенных СУБД.
курсовая работа [434,7 K], добавлен 20.07.2012Общая характеристика СУБД MySQL, клиент-серверная технология. Отличительные черты физической организации хранения и обработки данных, имеющимся в СУБД MySQL. Средства администрирования и спектр программных интерфейсов. Характер связи между таблицами.
презентация [73,2 K], добавлен 28.05.2019Система управления базами данных как составная часть автоматизированного банка данных. Структура и функции системы управления базами данных. Классификация СУБД по способу доступа к базе данных. Язык SQL в системах управления базами данных, СУБД Microsoft.
реферат [46,4 K], добавлен 01.11.2009Структура и функции системы управления базами данных (СУБД). Управление хранением данных и доступом к ним. Защита и поддержка целостности данных. Надежность хранения данных во внешней памяти. Классификация СУБД по способу доступа к базе данных.
презентация [3,7 M], добавлен 05.06.2014Характеристика и правила организации баз данных - совокупности взаимосвязанных данных, характеризующихся возможностью использования для большого количества приложений; возможностью быстрого получения и модификации необходимой информации. Выбор СУБД.
реферат [1,4 M], добавлен 27.10.2010
