Введение
Тема курсовой работы «Управление базами данных».
Информационные системы главным образом ориентированы на хранение, выбор и модификацию имеющейся информации. Хотя структуры данных различны в разных информационных системах, между ними часто бывает много общего. Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось одной из причин появления СУБД (систем управления базами данных).
Именно СУБД решают множество проблем, которые не покрываются возможностями систем управления файлами. Среди них можно выделить:
- поддержание логически согласованного набора файлов;
- обеспечение языка манипулирования данными;
- восстановление информации после разного рода сбоев;
- реально параллельная работа нескольких пользователей.
Цель работы – рассмотреть основные функции СУБД, реляционные СУБД, настольные реляционные базы данных и корпоративные СУБД.
1. Реляционные СУБО
1.1 Основные понятия
На сегодняшний день реляционные СУБД получили наибольше распространение. В таких СУБД данные хранятся в таблицах, связанных между собой.
На начальном этапе моделирования данных обеспечиваются наиболее естественные для человека способы сбора и представления той информации, которую предполагается хранить в создаваемой базе данных (это так называемая инфологическая модель данных). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность- любой различимый объект (объект, который мы можем отличить от других объектов), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, рабочие места, приказы, организации и т. д. Например, типом сущности может быть СОТРУДНИК, а ее экземплярами - Иваненко, Сидорчук, Кравченко. Экземплярами сущности ОРГАНИЗАЦИИ являются, например, ООО «АМИ», ЗАО «Спектр», ОАО «Трасмаш».
Атрибут- это поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Например, АДРЕС может быть определен для многих сущностей: СОТРУДНИК, ОРГАНИЗАЦИЯ и т. д. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности СОТРУДНИК являются ФАМИЛИЯ, ИМЯ, ОТЕЧЕСТВО, ДОЛЖНОСТЬ, ОКЛАД, ПРИКАЗ, АДРЕС и т. д.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.
Ключ- это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся атрибутам. Например, для сущности СОТРУДНИК ключом является атрибут ТАБЕЛЬНЫЙ №.
Связь - ассоциирование двух или более сущностей. Одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи.
1.2 Типы связей
Между двумя сущностям, например А и В, возможны четыре вида связей.
Связь «один-к-одному» (1:1). В каждый момент времени каждому представителю (экземпляру) сущности А только один экземпляр сущности В. Например, каждый СОТРУДНИК имеет один внутренний ПАСПОРТ.
Связь «один-ко-многим» (1:М). Одному представителю сущности А соответствует соответствуют 0, 1 или несколько представителей сущности В.
Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи «многие-к-одному» (М:1) (обратный связи «один-ко-многим») и «многие-ко-многим» (M:N), когда каждому экземпляру сущности А может соответствовать 0, 1 или не-сколько экземпляров сущности В, и наоборот. Как пример такой связи можно представить соотношение между СОТРУДНИКАМИ и ЯЗЫКАМИ (иностранными).
1.3 Первичные и внешние ключи
Как было определено выше, ключ - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Каждая сущность обладает хотя бы одним возможным ключом, причем один из них принимается за первичный ключ. При выборе первичного ключа нецелесообразно использовать ключи с длинными текстовыми значениями, а предпочтительнее использовать целочисленные атрибуты. Так, для идентификации СОТРУДНИКА можно использовать либо ТАБЕЛЬНЫЙ №, либо набор из ФАМИЛИИ, ИМЕНИ, ОТЧЕСТВА, ОТДЕЛА, так как не исключено наличие в базе данных двух сотрудников с одинаковыми фамилиями и именами.
Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.
Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.
1.4 Целостность
Под целостностью (от англ. integrity
- неприкосновенность, целостность) понимается правильность данных в любой момент времени. СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных. Например, нельзя обнаружить, что вводимое значение 14 (представляющее количество дней отпуска сотрудника) в действительности должно быть равно 24. Но с другой стороны, значение 94 явно будет ошибочным и СУБД должна его отвергнуть. Естественно, это произойдет только в том случае, если СУБД будет указано, что количество дней отпуска не должно превышать значение 60.
Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений. Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).
Выделяют три группы правил целостности:
- целостность по сущностям;
- целостность по ссылкам;
- целостность, определяемая пользователем.
1.5 Реляционная модель данных
Модель данных описывает некоторый набор понятий и признаков, которыми должны обладать СУБД и управляемые ими базы данных, которые основаны на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации с помощью одного общего языка.
Первой формализованной и общепризнанной моделью данных была реляционная модель Кодда. Структуры данных в реляционной модели основываются на плоских нормализованных отношениях, ограничения целостности выражаются с помощью средств логики первого порядка и, наконец, манипулирование данными осуществляется на основе реляционной алгебры. Кодд показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение - relation
(англ.).
Основными понятиями реляционной модели являются (рис. 1.1):
- отношение (таблица);
- домен (значения столбца);
- атрибут (столбец, поле);
- кортеж (строка, запись).
Рис. 1.1. Определяющие компоненты реляционной базы данных
Наименьшая единица данных реляционной модели - это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой - как три различных значения. Наиболее правильной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен «Фамилия» в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут отображать фамилию. Данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов ФАМИЛИЯ и ИМЯ относятся к типу строковых данных, но не являются сравнимыми.
Тип данных в реляционной модели данных полностью соответствует типу данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых, логических данных, дат, времени, временных интервалов, МЕМО-полей и др.
Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)} (рис. 1.2). Степень или «арность» схемы отношения - мощность этого множества. Схема базы данных (в структурном смысле) - это набор именованных схем отношений. Отношение - это множество кортежей, соответствующих одной схеме отношения.
Рис. 1.2. Графическое представление отношений в настольной базе данных Access 2000
Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.
Хотя Коддом были сформулированы 12 правил для реляционных баз данных (БД), но, собственно говоря, первые два составляют суть реляционных баз данных и достаточно понятны даже рядовым пользователям. Так, правило 1 (информационное правило) гласит о том, что вся информация в реляционной базе данных представляется как набор значений, хранящихся в таблицах. Правило 2(правило гарантии доступа) определяет, что доступ к каждому элементу данных в реляционной базе данных можно получить с помощью имени таблицы, первичного ключа и названия столбца.
1.6 Реляционная БД
Распространенным представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра (см. рис. 1.1). В этом случае имена атрибутов именуют столбцы этой таблицы, поэтому иногда говорят столбец таблицы, имея в виду атрибут отношения. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Реляционная база данных - это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.
Основными признаками реляционной базы данных являются следующие:
- каждая таблица состоит из однотипных строк и имеет уникальное имя;
- строки имеют фиксированное число полей (столбцов) и значений, т. е. в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего;
- строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы;
- столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных;
- при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке независимо от их содержания.
1.7 Основные функции СУБД
Управление данными во внешней памяти.
Информация из БД хранится во внешней памяти, а в некоторых СУБД используются возможности существующих файловых систем. В то же время развитые СУБД поддерживают собственную систему именования объектов БД.
Управление оперативной памятью.
Если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью этого устройства. Чтобы ускорить обработку БД, их нужно размещать в оперативной памяти. Но так как СУБД оперируют БД, размер которых обычно существенно больше доступной оперативной памяти, то требуется буферизация (разбиение на части и последовательная обработка) данных в оперативной памяти. Буферизация данных может выполняться как ОС (общесистемная буферизация), так и самой СУБД.
Управление транзакциями.
Последовательность операций над БД, рассматриваемых СУБД как единое целое, называется транзакцией и поддерживает логическую целостность БД. С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализации параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения.
Журнализация.
При хранении данных во внешней памяти должен обеспечиваться необходимый уровень надежности, т. е. СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Сбои бывают двух типов: «мягкие» (без потери данных на устройствах внешней памяти), например, при аварийной остановке работы компьютера из-за отключения питания или из-за ошибки в программе, и «жесткие», характеризуемые потерей данных. К программным сбоям можно отнести, например, аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной.
Очевидно, что независимо от типа сбоя для восстановления БД нужно иметь некоторые дополнительные сведения, которые имеются и в журнале изменений БД. Это недоступная пользователям СУБД часть БД, в которую заносятся записи обо всех изменениях основной части БД. При занесении записей в журнал поддерживается протокол «упреждений» (Write Ahead Log - WAL), т. е. запись об изменении любого объекта БД попадает во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД.
Для восстановления БД после «мягкого» сбоя необходимо выполнить откат транзакции, а для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. При этом под архивной копией понимают полную копию БД к моменту начала заполнения журнала.
Поддержка языков БД.
Для работы с базами данных используются специальные языки, называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных языков, среди которых чаще всего использовались язык определения схемы БД (SDL - Schema Definition Language)
и язык
манипулирования данными (DML - Data Manipulation Language).
Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), который сочетает в себе средства SDL и DML, т. е. позволяет определять схему реляционной БД и манипулировать данными. SQL содержит специальные средства определения ограничений целостности БД, а его специальные операторы позволяют определять так называемые представления БД, которые фактически являются хранимыми в БД запросами. Результатом любого запроса к реляционной БД является таблица с именованными столбцами.
1.8 Язык запросов SQL
Язык SQL (Structered Query Language - язык структурированных запросов) появился более 30 лет назад в рамках проекта экспериментальной реляционной СУБД под названием System R. Сначала он назвался SEQUEL (Structered English Query Language).
Практически одновременно с появлением первых его коммерческих реализаций SQL появился и первый его стандарт ANSI/ISO (1985 г.). Вскоре появился SQL 92, который охватывает практически все необходимые для реализации аспекты: манипулирование схемой БД, управление транзакциями и сессиями (последовательностью транзакциями, в пределах которой сохраняются временные отношения), подключение к БД, динамический SQL, стандартизованы отношения-каталоги.
Существенными свойствами запросов SQL являются возможность простого формулирования запросов с соединениями нескольких отношений и использование вложенных подзапросов. Вообще говоря, одновременное наличие обоих средств избыточно, но это дает пользователю при формулировании запроса возможность выбора более понятного ему варианта.
Еще одной важной особенностью SQL является возможность указания в запросе потребности группирования отношения-результата по указанным полям с поддержкой условий выборки на всю группу целиком. Такие условия выборки могут содержать агрегатные функции, вычисляемые на группе.
Кроме того, в SQL является необязательным удаление кортежей-дубликатов в окончательной или промежуточных таблицах. Строго говоря, результатом оператора выборки (SELECT) в языке SQL является не отношение, а множество кортежей.
Самый общий вид запроса на языке SQL представляет выражение, составленное из элементарных запросов. В SQL System R допускались все базовые теоретико-множественные операции (UNION, INTERSECT и MINUS).
Операторы манипулирования данными UPDATE и DELETE построены на тех же принципах, что и оператор выборки данных SELECT. Набор кортежей указанного отношения, подлежащих модификации или удалению, определяется входящим в соответствующий оператор логическим выражением, которое может включать сложные предикаты, в том числе и с вложенными подзапросами.
В настоящее время SQL реализован практически во всех коммерческих реляционных СУБД в графическом виде (рис. 5.3). Если воспользоваться режимом SQL для приведенного запроса, то он будет выглядеть следующим образом:
SELECT PERSONS.PERSONA, PERSONS.FAMILIA, PERSONS.IMIA, PERS.ONS.OTCHEST, PERSONS.IDNUM, PERSONS.TABNUM
FROM PERSONS
WHERE (((PERSONS.IMIA) = «Сергей») AND ((PERSONS.TABNUM)>10));
Особенностью большинства современных коммерческих СУБД, затрудняющей анализ существующих диалектов SQL, является отсутствие полного описания языка. Тем не менее, можно сказать, что базовый набор операторов SQL, включающий операторы определения схемы БД, выборки и манипулирования данными, авторизации доступа к данным, поддержки встраивания SQL в языки программирования и операторы динамического SQL, в коммерческих выпусках устоялся и более или менее соответствует стандарту.
Рис. 1.3. Пример использования SQL в настольной СУБД
2. Настольные реляционные базы данных
2.1 Общие замечания
Настольные СУБД как таковые не содержат специальных приложений и служб, управляющих данными, - взаимодействие с ними осуществляется с помощью файловых служб самой ОС. Нередко подобные СУБД имеют в своем составе и средства разработки, ориентированные на работу с данными поддерживаемого ими формата. Обработка данных в таких системах полностью осуществляется в пользовательском (клиентском) приложении, хотя появляются и сетевые многопользовательские версии настольных СУБД, позволяющие обрабатывать данные, находящиеся в общедоступном хранилище (например, на сетевом диске) нескольким пользователям одновременно. Многопользовательские версии отличаются наличием механизма блокировок частей файлов данных (содержащих одну или несколько записей таблицы), что позволяет обращаться к одному и тому же файлу нескольким пользователям одновременно.
Недостатки настольных СУБД становятся заметны, как правило, при увеличении хранимых объемов данных и увеличении числа работающих с ними пользователей. Обычно они проявляются в снижении производительности и в возникновении сбоев при обработке данных. Причина подобных проблем кроется в основном принципе работы таких СУБД и обработке данных внутри пользовательского приложения. Еще одна проблема настольных СУБД заключается в возможности нарушения ссылочной целостности данных, так как единственным механизмом, контролирующим ее, является клиентское приложение. Поэтому все пользовательские приложения должны содержать соответствующий код и доступ к файлам базы данных из любых других приложений должен быть запрещен.
На сегодняшний день известно множество настольных СУБД, однако наиболее популярными являются dBase, Paradox, FoxPro и Access. Особо нужно отметить Microsoft Data Engine (MSDE) - по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server, но предназначенную для использования главным образом в настольных системах.
2.2 Краткая характеристика настольных систем
2.2.1 dBase и Visual dBase
Хранение данных в dBase
(
www.dbase2000.com) основано на принципе «одна таблица - один файл» (эти файлы обычно имеют расширение *.dbf). МЕМО-поля и BLOB-поля, как и индексы для таблиц, хранятся в отдельных файлах (обычно с расширением *.dbt). Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД.
Для работы с данными формата dBase (или иных dBase-подобных СУБД) совершенно необязательно пользоваться диалектами собственного языка xBase. Доступ к этим данным возможен с помощью ODBC API (и соответствующих драйверов) и некоторых других механизмов доступа к данным, и это позволяет создавать приложения, использующие формат данных dBase, практически с помощью любого средства разработки, поддерживающего один из этих механизмов доступа к данным.
Дальнейшее продолжение dBase получила в продукте Visual dBase, который приобрел набор дополнительных возможностей, среди которых специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД.
2.2.2 Paradox
Принцип хранения данных в Paradox
(www.corel.com) сходен с принципами хранения данных в dBase - каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.рх). Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки.
Windows-версии СУБД Paradox позволяют манипулировать данными других форматов, в частности dBase и данными, хранящимися в серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных.
2.2.3 Microsoft FoxPro и Visual FoxPro
По сравнению с аналогичными версиями dBase, FoxBase
(www.micro-soft.com) и более поздняя версия этого продукта, получившая название FoxPro, предоставляли своим пользователям несколько более широкие возможности, такие как использование деловой графики, генерация кода приложений, автоматическая генерация документации к приложениям и т. д.
Последняя версия этого продукта - Visual FoxPro, доступна и отдельно, и как составная часть Microsoft Visual Studio 6.0. Ее отличительной особенностью от двух рассмотренных выше является интеграция с технологиями Microsoft, в частности поддержка COM (Component Object Model - компонентная объектная модель, являющаяся основой функционирования 32-разрядных версий Windows), интеграция с Microsoft SQL Server.
2.2.4 Microsoft Access
В отличие от СУБД Visual FoxPro, фактически превратившейся в средство разработки приложений, Access
(www.microsoft.com) (рис. 2.1) ориентирована на пользователей Microsoft Office. В состав Access входят средства манипуляции данными Access и данными, доступными через ODBC, средства создания форм, отчетов и приложений; при этом отчеты могут быть экспортированы в формат Microsoft Word или Microsoft Excel, а для создания приложений используется Visual Basic for Applications, общий для всех составных частей Microsoft Office и др.
Рис. 2.1. Одна из самых популярных настольных СУБД, используемых в малом бизнесе
Поддержка модели СОМ в Access выражается в возможности использовать элементы управления ActiveX в формах и Web-страницах, созданных с помощью Access. В отличие от Visual FoxPro создание СОМ-серверов с помощью Access не предполагается.
2.2.5 Microsoft Data Engine
MSDE
(www.microsoft.com) представляет собой СУБД, базирующуюся на технологиях Microsoft SQL Server, но предназначенную для использования в настольных системах или в сетевых приложениях с объемом данных до 2 Гбайт и небольшим количеством пользователей. По существу MSDE является облегченной версией Microsoft SQL Server, не содержащей средств администрирования, и к настольным СУБД может быть отнесена весьма условно.
В Microsoft Access пользователь может выбрать, какой механизм доступа к данным следует применять: Microsoft Jet - стандартный набор библиотек доступа к данным или MSDE (в этом случае управление базой данных осуществляется с помощью отдельного процесса). Возможно преобразование имеющихся баз данных Access в базу данных MSDE из среды разработки Access.
Базы данных MSDE полностью совместимы с базами данных Microsoft SQL Server и могут при необходимости управляться этим сервером. Как большинство серверных СУБД, эти базы данных поддерживают транзакции, позволяют создавать триггеры и хранимые процедуры (недоступные в базах данных Access).
3. Корпоративные СУБД
3.1 Серверы баз данных
Данный термин обычно используют для обозначения всей СУБД, основанной на архитектуре клиент-сервер, включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных для всех пользователей локальной сети.
Доступ к базе данных от приложения и
Сервер баз данных отвечает за работу с файлами базы данных, поддержку ссылочной целостности, резервное копирование, обеспечение авторизованного доступа к данным, протоколирование операций и, конечно, за выполнение пользовательских запросов на выбор и модификацию данных и метаданных. Клиентские приложения, являющиеся источниками этих запросов, функционируют на персональных компьютерах в сети.
Не останавливаясь подробно на достоинствах и недостатках подобной архитектуры, отметим, что при использовании серверных СУБД выполнение запросов производится самим сервером, поэтому клиентские приложения получают от сервера только результаты самого запроса, что существенно снижает сетевой трафик при обработке запросов. Отметим также, что многие объекты, предназначенные для реализации бизнес-правил доступны лишь в серверных СУБД.
Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество -стандартность интерфейса. Явный недостаток - на таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная рабочая станция. Но если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы. Что собственно говоря и обусловило появление двух- и трехуровневых (звенных) систем.
3.2 Два уровня или три?
Информационные системы, созданные на основе классической клиент-серверной архитектуры, называются двухзвенными системами или системами с «толстым» клиентом. Они состоят из сервера баз данных, содержащего сгенерированные таблицы и другие объекты БД, реализующие бизнес-правила, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных согласно содержащимся в них алгоритмам (рис. 3.1).
Если приходится иметь дело с несколькими СУБД, то наиболее существенным является общий интерфейс доступа к данным. Наличие такого интерфейса позволяет использовать стандартные инструментальные средства и существенно упрощает процесс разработки приложения. К наиболее популярным интерфейсам относятся ODBC, OLE DB и ActiveX Data Object (ADO). В клиентских приложениях для доступа к источникам данных используются вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД.
Рис. 3.1. Структура 2-уровневой системы
В системах с так называемым «тонким» клиентом на клиентском компьютере отсутствует клиентская часть серверной СУБД. В этом случае функциональность, связанная с доступом к данным (а нередко и какие-либо иные функции), возлагается на другое приложение, называемое обычно сервером приложений, и являющееся клиентом серверной СУБД. В свою очередь, клиентские приложения обращаются не непосредственно к серверной СУБД, а к серверу приложений, являющемуся для них источником данных. Таким образом, сервер приложений является средним звеном в цепи «тонкий клиент - сервер приложений - сервер баз данных» (рис. 3.2) и, соответственно, относится к классу программных продуктов middleware.
Рис. 3.2. Клиент «утончается» за счет сервера приложений
В настоящее время промежуточное ПО (middleware) относится к любому программному компоненту, который располагается между пользовательскими приложениями на персональных (клиентских) компьютерах и реляционной СУБД или унаследованной системой, непосредственно управляющими необходимыми данными.
Направление объектно-ориентированных БД соединило в себе реляционные СУБД и развивающиеся языки программирования с абстрактными типами данных и объектно-ориентированными языками программирования (табл. 3.1). Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект, например Сотрудник, при создании получает уникальный идентификатор, который связан с ним все время его существования и не меняется при изменении состояния объекта.
Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта- набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.
Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования).
Допускается порождение нового класса на основе уже существующего класса - наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы.
Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует.
3.3 Краткая характеристика корпоративных (промышленных) СУБД
3.3.1 DB2 Universal Database
Универсальный сервер баз данных DB2 Universal Database
(www. ibm.com) - это масштабируемая объектно-реляционная система управления базами данных с интегрированной поддержкой мультимедиа и Web, работающая под управлением OS/2, Windows NT, различных версиях UNIX, на однопроцессорных и многопроцессорных симметричных системах.
DB2 базируется на нескольких ключевых современных технологиях:
- поддержка сложных объекто-ориентированных и мультимедийных типов данных;
- обеспечение доступа к данным через Интернет;
- сложные преобразования и анализ данных вместе с обеспечением высокой надежности, производительности и масштабируемости. Поддержка сложных типов данных, таких как изображения, видео, аудио и текст, полностью интегрирована с базой данных с помощью определяемых пользователем функций и типов данных. Она включает в себя мощные функции контекстно-зависимого поиска, а также встроенные функции для поддержки систем аналитической обработки в реальном времени (OLAP - On-Line Analytical Processing).
DB2 поддерживает большое количество национальных языков, в том числе для русского языка поддерживаются несколько кодовых страниц.
Таблица 3.1. Общие сведения о реляционных и объектных базах данных
| Реляционные базы данных | Объектно-реляционные базы данных | Объектные базы данных | |
Примеры продуктов |
ORACLE, Informix Dynamic Server, DB2, Openlngres, Miscrosoft SQL Server. Sybase. | ORACLE, Informix Universal Server, Universal Server, DB2, UniSQL, Cashe | ObjectStore, Gemstone, РОЕТ, 02, Versanf, Jasmine, ODB-Jupiter |
| Модель данных | Реляционная | Реляционная | Объектная |
| Понимание и использование | Тaбличные структуры легко воспринимаются, существует множество приложений | Табличные структуры легко воспринимаются, существует множество приложений | Существенно упрощается разработка прикладных программ, но пока их создано относительно немного |
| Новые типы данных | Система управления базами данных оперирует с ограниченным набором данных | Расширение типов универсального сервера (Informix, Oracle) требует сертификации дополнительных модулей (datablades, cartridges), их специального тестирования и вставки в ядро СУБД | Объектная база не требует модификации ядра при добавлении нового типа данных. Новый класс и его экземпляры просто поступают во внешние структуры базы данных |
ЯЗЫК СУБД и запросы |
Стандартный SQL2, хотя каждый производитель предлагает его диалекты | Язык манипуляции данными ОЬ-iectSQL полностью совместим с SQL2. Все приложения, использующие язык SQL для обмена с базой данных, будут работать субъектно-реляционной |
Язык описания объектов и запросов унифицирован с базовым языком программи-эования, например, с С++, Smalltalk, Java. Дополнительно іредоставляется язык объект-іьіх запросов OQL, который яв-яется SQL-подобным, но он не |
| Оптимизация S ядра СУБД i | Ідра реляционных СУБД опти- S визированы для выполнения С итераций над таблицами | Ядра объектно-реляционных СУБД оптимизированы для выпол- ч ения операций над таблицами | Полностью совместим с SOI ядра объектных СУБД изначально оптимизированы под использование объектов |
3.3.2 Centura SQLBase 7.5
Это сравнительно компактная по объему занимаемых ресурсов СУБД, используемая для создания бизнес-систем, в том числе ориентированных на Web-технологии. Сервер БД SQLBase (www.centura.conn)совместно с информационными системами и/или Web-приложениями позволяет создавать надежные и гибкие системы обработки данных, не требующие сложного администрирования и способные удовлетворить большинство потребностей разработчиков и пользователей.
Centura SQLBase 7.5
имеет все необходимые средства для администрирования и проектирования БД, эффективного взаимодействия с прикладными программами.
Для обеспечения работы в сети SQLBase поддерживает все общепринятые коммуникационные протоколы, например, TCP/IP, IPX/SPX, NetBios, и хранимые процедуры. Для доступа к данным SQLBase может использоваться любое средство, которое поддерживает ODBC.
SQLBase 7.5 поставляется в 3 вариантах: Standard, SafeGarde и SafeGarde Max.
3.3.3 Oracle9i
База данных Oracle9i
(www.oracle.ru)
нацелена на недавно сложившийся рынок Интернет-приложений. Она обладает возможностями кластеризации, мощными и экономичными средствами безопасности, исключает потери данных и позволяет интерактивно
обмениваться информацией. Oracle9i Database удовлетворит все потребности вашего электронного бизнеса в Интернете.
Модуль Oracle Real Application Clusters обеспечивает масштабируемость, не зависит от используемых компонентов и позволяет масштабировать вашу систему своими силами.
Oracle9i позволяет организовать непрерывный доступ к данным, практически исключая запланированные и аварийные задержки. Встроенные в Oracle°i средства управления системами позволяют контролировать все жизненно важные компоненты, занятые в процессах электронного бизнеса.
Модуль Oracle9i Data Warehouses обслуживает больше пользователей и анализирует оперативные данные быстрее, чем раньше. Модуль Oracle9i Dynamic Services - это открытая система с программным доступом, централизованным управлением и средствами организации многоканальных служб Интернета.
В Oracle9i улучшена встроенная поддержка языков Java и XML.
3.3.4 Oracle8i Server
В состав предварительно настроенного и сконфигурированного сервера Огасlе8і,
называемого также Oracle8i Standart Edition, входит интегрированный набор простых в использовании средств управления, тиражирования, репликации и работы в Web. Средства репликации и доступа к распределенным данным позволяют пользователям распределять реляционные данные между приложениями и серверами и совместно использовать их.
Интегрированное графическое средство Oracle Enterprise Manager (рис. 3.3) дает администраторам возможность выполнять задачи комплексного управления, используя операции типа «укажи и нажми». Сервер Oracle8i предоставляет пользователям новый уровень распределенных вычислений для рабочих групп. Системы клиент-сервер и «тонкий клиент» обладают самой высокой степенью распределенности.
Oracle8i обеспечивает единую систему управления базами данных, которая способна удовлетворить требованиям, предъявляемым новыми типами данных сейчас и в последующие годы. С помощью продукта Oracle interMedia Oracle8i может управлять текстами, изображениями, аудио и видео данными, привязкой данных к картам и схемам с той же степенью интеллектуальности, масштабируемости, защищенности и целостности, что и для структурированных данных.
3.3.5 Borland InterBase
Этот SQL-сервер баз данных (
www.borland.ru) объединяет простоту использования, низкие затраты на сопровождение и мощность систем корпоративного уровня. Сервер InterBase реализует архитектуру множественных поколений записей (MGA - Multi-Generational Architecture). Механизм MGA в InterBase хорошо работает при оперативной обработке коротких транзакций (OLTP - On-Line Transaction Processing) и обеспечивает своевременные, устойчиво воспроизводимые результаты для каждого запроса без специального программирования. В результате достигается максимальная пропускная способность для всех пользовательских транзакций.
К MGA сервер InterBase добавляет многопотоковую архитектуру, улучшая производительность и оптимизируя использование системных ресурсов, особенно при большом числе пользователей. Многопотоковая архитектура обеспечивает разделяемый кэш данных, сокращая число дисковых операций ввода-вывода для каждого запроса в приложении. Привлекательные свойства Java - простота, надежность, переносимость и гибкость - также характерны и для InterBase. Приложения на Java получают доступ к InterBase через драйвер JDBC InterClient.
InterBase придерживается строгого соответствия индустриальным стандартам для клиент-серверных сред, таким как ANSI/SQL, Java, UNICODE и XDR (External Data Representation - внешнее представление данных). При этом обеспечивается работа под управлением Windows 2000 (с Service Pack 1), NT 4.0 (с Service Pack 6), ME, 98, Red Hat 6.2, 7, Mandrake 7.2, SuSE 7.0, TurboLinux 6.0, Solaris 2.6, 7.
3.3.6 Microsoft SQL Server 2000
В сервер SQL Server 2000
(www.microsott.conn) включен поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения (рис. 3.4). Кроме того, SQL Server 2000 полностью использует все возможности Windows, включая поддержку до 32 процессоров.
К основным возможностям SQL Server 2000 относятся:
- доступ по протоколу HTTP, который поддерживает отправку SQL-запросов к БД с применением Интернет-адресов;
- полнотекстовый поиск позволяет выполнять поиск в тексте БД, а также в документах Word, таблицах Excel, PDF-файлах, что является критически важным для Web-применения;
- Microsoft English Query является средством формирования запросов на естественном (английском) языке, применяемым в клиентских приложениях и при работе через Интернет;
- интегрированное средство выявления закономерностей применяется, чтобы отбирать важную, но не обязательно очевидную, бизнес-информацию из больших наборов данных. Оно является компонентом средства Business Internet Analytics, обеспечивающего сбор, хранение, управление и анализ потока данных о действиях пользователей при посещении ими Web-сайта;
- связанные базы данных OLAP - это, в первую очередь, кубы OLAP, применяемые для реализации новых возможностей анализа данных; они позволяют повысить ценность данных за счет предоставления возможностей анализа OLAP через Web;
- сервер Commerce Server и средство Business Internet Analytics используются для анализа работы пользователей на Web-узле по зарегистрированным данным о Web-трафике;
- распределенные разделенные представления (Distributed Partitioned Views) обеспечивают неограниченную масштабируемость для приложений электронной коммерции;
- выполняемая без перехода в автономный режим параллельная проверка DBCC (Database Consistency Check - проверка совместимости БД) обеспечивает целостность данных;
- усовершенствованная архивация базы данных основана на копировании только того, что изменилось с момента последней архивации (самый быстрый способ резервного копирования);
- архивация с созданием «мгновенных снимков» производится в системах с зеркалированием без прерывания работы;
- интегрированные службы анализа служат основой для обработки OLAP;
- динамические автоматическое управление и настройка экономят время при установке и настройке;
- мастер копирования баз данных позволяет администраторам легко перемещать и копировать базы данных без перехода в автономный режим;
- диспетчер SQL Server Enterprise Manager обладает новыми возможностями, включая усовершенствованные средства разработки схем, интеграцию репозитариев, интерактивный анализ и отладку запросов;
- службы преобразования данных предоставляют интегрированные, удобные в использовании и быстродействующие средства извлечения, изменения, преобразования и загрузки данных;
- поддержка многих языков позволяет «на лету» менять язык пользовательского интерфейса.
3.3.7 Cache 5
Это постреляционная промышленная СУБД от компании InterSystems (
www.intersystems.com), интегрированная с технологией разработки Web-приложений - Cache Server Pages. Она имеет единую архитектуру данных и поддерживает объектно-ориентированные технологии. Cache поддерживает следующие ОС: все версии Windows и Linux, основные реализации Unix и Open VMS.
Данные в Cache
хранятся под управлением многомерного сервера данных (рис. 3.5). В ее основе лежит транзакционная многомерная модель данных (ТММД), которая позволяет хранить и представлять данные так, как они чаще всего используются. ТММД позволяет избежать проблем, присущих реляционным СУБД, оптимизируя данные на уровне хранения.
В Cache реализована концепция единой архитектуры данных. К одним и тем же данным, хранящимся под управлением многомерного сервера данных Cache, существует 3 способа доступа:
- прямой;
- объектный;
- реляционный.
Прямой доступ к данным обеспечивает максимальную производительность и полный контроль со стороны программиста. Реляционный доступ - Cache SQL обеспечивает максимальную производительность реляционных приложений с использованием встроенного SQL. В Cache реализована и объектная модель. Для реализации бизнес-логики БД в Cache используется Cache Object Script - полнофункциональный язык, который имеет все необходимые механизмы для работы с данными независимо от способа доступа.
Разработчик может реализовывать приложения клиент-сервер, используя практически все средства разработки. При этом он может использовать специальные интерфейсы для прямого и объектного доступа, а стандартные (ODBC, JDBC) - для реляционного. В Cache реализована полноценная поддержка XML. Полная поддержка объектной модели позволяет автоматически трансформировать сложные XML-документы в классы объектов Cache.
3.3.8 Sybase
Компания Sybase (www.sybase.ru) разработала базы данных, оптимизированные под требования и нужды различных бизнесов:
- Adaptive Server Enterprise;
- Adaptive Server Anywhere;
- Adaptive Server IQ.
Сервер баз данных Sybase Adaptive Server IQ
специально разработан для высокоскоростного анализа данных. Благодаря использованию технологии обработки запросов, уникальных способов
индексирования и алгоритмов, оптимизирующих производительность, удалось увеличить скорость выполнения произвольных запросов и поддерживать производительность, несмотря на увеличение числа пользователей и на изменение типов запросов в зависимости от потребностей бизнеса.
Sybase Adaptive Server IQ Multiplex
использует особый, ориентированный на столбцы, метод хранения данных. Такой подход в сочетании с новыми индексными технологиями, преодолевающими ограничения традиционных индексов, значительно ускоряет процесс выполнения запросов и снижает требования к объему дискового пространства. Скорость загрузки с полной индексацией составляет до 40 Гбайт/час.
Sybase Adaptive Server Enterprise
(ASE) 12.5 разработан как для создания и поддержки традиционных OLTP- и распределенных приложений, так и для развития интернет/интранет систем. Это готовая к использованию в портальных и Интернет-решениях система, которая содержит множество новых возможностей и усовершенствований.
Adaptive Server Anywhere
(ASA) 6.0 - это новая расширенная и оптимизированная версия Sybase SQL Anywhere. Отличительными чертами этой СУБД являются невысокие требования к ресурсам (можно начинать работать, когда в машине всего 2 Мбайт оперативной памяти), поддержка различных аппаратных платформ и операционных систем (Windows 3.11/95/98/NT/CE, Novell NetWare и всех основных версий UNIX), невысокая цена.
Сферы применения ASA - прежде всего те приложения, в которых традиционно использовались настольные БД: расчет зарплаты, складской учет, учет персонала и др. ASA может использоваться в качестве удаленной БД или настольной системы, а также как расширение существующей информационной системы предприятия. При этом она полностью поддерживает возможности SQL-сервера, а входящий в состав поставки SQL Remote - метод передачи выполненных транзакций от одной СУБД к другой - позволяет создавать распределенные приложения.
Другой метод тиражирования данных - использование Replication Server, также поддерживаемого в ASA с помощью Replication Agent. С его помощью можно осуществлять практически мгновенную синхронизацию данных, создавать систему «горячего» резервирования, тиражировать данные в разнородные БД.
ASA поддерживает два стандарта - Transact-SQL и Watcom SQL (включая SQL в стандарте ANSI 92). При этом Transact-SQL совместим с языком SQL СУБД Sybase Adaptive Server Enterprise, обладающей еще
более высокими возможностями в аспекте масштабируемости и производительности.
В ASA 6.0 улучшен оптимизатор запросов. Теперь имеется возможность кэширования повторно вызываемых запросов. Кроме того, можно получить план запроса для оценки оптимизации и корректировки.
3.3.9 MySQL
Набирающий популярность SQL-сервер - mySQL
(
www.mysgl.com) -это компактный многопоточный сервер баз данных, который характеризуется большой скоростью, устойчивостью и легкостью в использовании. mySQL является эффективным решением для малых и средних приложений. Наиболее полно возможности сервера проявляются на Unix-серверах, где есть поддержка многопоточности, что дает значительный прирост производительности.
mySQL-сервер является бесплатным для некоммерческого использования. Иначе необходимо приобретение лицензии, стоимость которой составляет не более 200 долларов.
Этот SQL-сервер поддерживает язык запросов SQL в стандарте ANSI 92 и, кроме этого, имеет множество расширений к этому стандарту. Возможно, mySQL самый быстрый сервер из существующих, но для достижения этого разработчикам пришлось пожертвовать некоторыми требованиями к реляционным СУБД. Так в mySQL отсутствуют поддержка вложенных запросов, не реализована поддержка транзакций и внешних ключей, а это приводит к тому, что в разработанных приложениях при переходе на эту СУБД могут оказаться неработоспособными некоторые функции бизнес-логики или получение каких-то отчетов.
3.3.10 PostgreSQL
Это бесплатный и вместе с тем достаточно мощный SQL-сервер (www.postaresgl.com), который включен в состав многих современных дистрибутивов Linux. Этот сервер баз данных относится к объектно-реляционным базам данных.
Последняя версия PostgreSQL полностью совместима с начальным уровнем SQL ANSI 92, она поддерживает большинство SQL-конструкций, включая транзакции, подзапросы, а также типы и функции, определяемые пользователем. PostgreSQL - первая из некоммерческих баз данных, которая может поддерживать «экзотические» типы данных и модели анализа, такие, как, например, вывод геометрических данных в трех измерениях.
Вывод
В процессе выполнения курсовой работы мы изучили и обобщили полученные знания по СУБД (системе управления базами данных).
Мы выяснили, что именно СУБД решают множество проблем, которые не покрываются возможностями систем управления файлами. Среди этих проблем:
- поддержание логически согласованного набора файлов;
- обеспечение языка манипулирования данными;
- восстановление информации после разного рода сбоев;
- реально параллельная работа нескольких пользователей.