49302 (Управление базами данных), страница 2

Для работы с базами данных используются специальные языки, называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных языков, среди которых чаще всего использовались язык определения схемы БД (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 в настольной СУБД

1. Настольные реляционные базы данных

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).

1. Корпоративные СУБД

3.1 Серверы баз данных

Данный термин обычно используют для обозначения всей СУБД, основанной на архитектуре клиент-сервер, включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных для всех пользователей локальной сети.

Доступ к базе данных от приложения или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL.

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

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

Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество -стандартность интерфейса. Явный недостаток - на таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная рабочая станция. Но если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы. Что собственно говоря и обусловило появление двух- и трехуровневых (звенных) систем.

3.2 Два уровня или три?

Информационные системы, созданные на основе классической клиент-серверной архитектуры, называются двухзвенными системами или системами с «толстым» клиентом. Они состоят из сервера баз данных, содержащего сгенерированные таблицы и другие объекты БД, реализующие бизнес-правила, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных согласно содержащимся в них алгоритмам (рис. 3.1).

Если приходится иметь дело с несколькими СУБД, то наиболее существенным является общий интерфейс доступа к данным. Наличие такого интерфейса позволяет использовать стандартные инструментальные средства и существенно упрощает процесс разработки приложения. К наиболее популярным интерфейсам относятся ODBC, OLE DB и ActiveX Data Object (ADO). В клиентских приложениях для доступа к источникам данных используются вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД.