Реляционные базы данных на основе SQL Server 2000

 

•     В SQL Server 2000 введен новый  параметр PHYSICAL_ONLY, который позволяет ускорить работу операторов DBCC, заставляя их проверять лишь те типы ошибок, которые, по всей вероятности, сгенерированы в результате аппаратных сбоев. Следует запускать проверку DBCC с параметром PHYSICAL_ONLY, если есть подозрение на наличие аппаратной ошибки на сервере баз данных.

 

•     Операторы DBCC сами по себе стали работать значительно  быстрее. Проверка сложной базы данных выполняется, как правило, в 8—10 раз  быстрее, а отдельных объектов —  более чем в 300 раз быстрее. В SQL Server 6.5 DBCC CHECKDB обрабатывал таблицы последовательно. Для каждой таблицы сначала выполнялась проверка структуры данных, а затем проверка каждого индекса по отдельности. В результате этой процедуры операции чтения совершались довольно хаотично. В SQL Server 2000 DBCC CHECKDB по мере последовательного сканирования базы данных выполняет параллельную проверку нескольких объектов. SQL Server 2000 также использует преимущества многопроцессорности при параллельном исполнении операторов DBCC.

 

•     Уровень блокировки, который требуется операторам DBCC из SQL Server 2000, намного ниже, чем в SQL Server 7.0. Теперь операторы DBCC из SQL Server 2000 могут выполняться одновременно с операторами модификации данных, что существенно снижает их негативное влияние на работу пользователей с базой данных.

 

•     Операторы DBCC из SQL Server 2000 способны сами исправлять замеченные ими небольшие ошибки. Также они  могут исправлять некоторые ошибки в структуре двоичного дерева индексов или ошибок в некоторых распределяемых структурах.

 

Принципы репликации

 

Репликация — это набор технологий, который позволяет поддерживать несколько копий одних и тех  же данных на нескольких узлах, число  которых иногда может достигать  нескольких сотен. Для распределения  данных при репликации используется модель публикации и подписки.

 

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

 

•     Подписчиком является сервер, который получает данные, реплицируемые издателем. Подписчик определяет подписку на определенную публикацию. В подписке указан срок получения подписчиком публикации и сведения о соответствии между статьями публикации и таблицами или другими объектами подписчика.

 

•     Дистрибьютор — это  сервер, выполняющий различные задачи по перемещению статей от издателей  к подписчикам. Реальные задачи зависят  от типа выполняемой репликации.

 

SQL Server 2000 также поддерживает репликацию  между гетерогенными источниками данных. Источники данных OLE DB или ODBC могут подписываться на публикации SQL Server. Последний также способен получать данные, реплицируемые некоторыми другими источниками данных, в том числе Microsoft Exchange, Microsoft Access, Oracle и DB2.

 

Хранилища данных и оперативная аналитическая обработка (OLAP)

 

SQL Server 2000 содержит компоненты, позволяющие  создавать хранилища и киоски  данных. Хранилища и киоски данных  можно использовать в сложных  промышленных системах искусственного  интеллекта, обрабатывающих запросы, которые применяются для выявления трендов и анализа критических факторов. Эти системы называются системами оперативной аналитической обработки (Online  Analytical Processing, OLAP). Данные в хранилищах и киосках данных организованы иначе, чем в традиционных базах данных, работающих с транзакциями.

 

ПО управления реляционными базами данных промышленного уровня, например SQL Server 2000, изначально разрабатывалось  для централизованного хранения данных, генерируемых ежедневными транзакциями крупных компаний или правительственных организаций. За десятилетия эволюции эти СУБД превратились в высокоэффективные системы регистрации данных, необходимые для ежедневной работы предприятия. Такие системы получили название систем оперативной обработки транзакций (Online Transaction-Processing, OLTP).

 

OLTP-системы

 

Данные в OLTP-системах организованы главным образом для поддержки  таких транзакций, как:

 

•     регистрация заказа, введенного с кассового терминала  или через Web-узел;

 

•     размещение заказа на комплектующие изделия, когда их количество на складе становится меньше определенного уровня;

 

•     отслеживание компонентов  во время сборки конечного продукта на производстве;

 

•     регистрация сведений о работниках;

 

•     регистрация идентификационных  данных держателей лицензий, например владельцев ресторанов или водителей.

 

Отдельные транзакции, обращаясь к  относительно небольшому объему данных, завершаются быстро. Системы OLTP созданы  и оптимизированы для одновременной  обработки сотен и тысяч транзакций.

 

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

 

OLAP-системы

 

Системы для обработки запросов, предназначенных для выявления  трендов и критических факторов, называются OLAP-системами. Как правило, запросы OLAP извлекают большой объем данных. Например, начальнику правительственного отдела по выдаче водительских прав, может понадобиться отчет по маркам и моделям автомобилей, которые регистрировались ежегодно в течение последних 20 лет. При выполнении запроса такого типа в системе OLTP:

 

•     значительное время  потребуется на агрегацию (суммирование) всех подробных записей за последние 20 лет, так что отчет не будет  подготовлен вовремя;

 

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

 

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

 

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

 

Архитектура разработки приложений

 

Для доступа к базе данных приложения используют два компонента: API или URL (Uniform Resource Locator — унифицированный указатель ресурса), а также язык баз данных.

 

API и URL

 

API определяет способ программирования  приложения для подключения к  базе данных и передаче ей  команд. Объектная модель API обычно  не зависит от языка и определяет  набор объектов, свойств и интерфейсов. API С или Visual Basic определяет набор функций для приложений, написанных на С, С++ или Visual Basic.

 

URL представляет собой строку  или поток, с помощью которого  Интернет-приложение получает доступ  к ресурсам Интернета или  интрасети. Microsoft SQL Server 2000 поддерживает библиотеку ISAPI (Internet Server Application Programming Interface), которую приложения IIS (Microsoft Internet Information Services) используют для создания URL, указывающих на экземпляры SQL Server 2000.

 

API, поддерживаемые SQL Server

 

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

 

•     ActiveX Data Objects (ADO);

 

•     OLE DB;

 

•     ODBC и объектные API, построенные на его основе — Remote Data Objects (RDO) и Data-Access Objects (DAO);

 

•     Embedded SQL для C (ESQL);

 

•     библиотека DB-Library для API C, разработанная специально для использования с ранними версиями SQL Server, предшествовавшими стандарту SQL-92.

 

Интернет-приложения также могут  применять URL, указывающие на виртуальные  корневые каталоги IIS, которые ссылаются  на экземпляр SQL Server. Зачастую URL содержит XPath-запрос, оператор Transact-SQL или шаблон. В дополнение к использованию URL, Интернет-приложения способны работать с данными в форме документов XML с помощью ADO или OLE DB.

 

Язык баз данных

 

Синтаксис команд, которые посылаются базе данных, определяется языком баз данных. Эти команды пересылаются через API, что дает приложениям возможность обращаться к данным и модифицировать их. Они также позволяют приложениям создавать и модифицировать объекты базы данных. Исполнение всех команд зависит от прав доступа, предоставленных пользователю. SQL Server 2000 поддерживает два языка: Transact-SQL и запросы XPath со схемами соответствия, применяемые в Интернет-приложениях, работающих в IIS.

 

Transact-SQL

 

Transact-SQL — это язык баз данных, поддерживаемый SQL Server 2000. Transact-SQL соответствует стандарту SQL-92 начального уровня, а также поддерживает некоторые функции промежуточного и полного уровней. Transact-SQL также содержит некоторые мощные расширения по сравнению со стандартом SQL-92.

 

Расширения определены в спецификации ODBC и поддерживаются OLE DB. Transact-SQL поддерживает расширения ODBC в приложениях, использующих API ADO, OLE DB или ODBC, или API, расположенные поверх ODBC. Расширения ODBC SQL не поддерживаются в приложениях, использующих API DB-Library или Embedded SQL.

 

XPath

 

SQL Server 2000 поддерживает  подмножество языка XPath, определенного  World Wide Web Consortium (W3C). XPath — это язык  навигации по графам, который  используется для выбора узлов  из документов XML. Прежде всего,  с помощью схемы соответствия определяется представление данных из одной или нескольких таблиц или представлений SQL Server в виде XML, а затем с помощью запросов XPath можно получать данные из этой схемы соответствия.

 

Запросы XPath обычно используются в URL или API ADO. API OLE DB также поддерживает запросы XPath.