Курсовая работа: Управление базами данных

Собирательное название 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