Приложение В

Дополнительные службы

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

В этом приложении представлены перечисленные ниже темы.

Служба Analysis Services. Становление этой службы началось с создания надежной машины оперативной аналитической обработки (Online Analytical Processing- OLAP), но со временем она превратилась в гораздо более мощный программный продукт. С помощью службы Analysis Services обеспечивается также интеллектуальный анализ данных, тогда как для этого другие компании часто предлагают отдельные коммерческие программные продукты.

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

Служба Service Broker. Эту службу можно рассматривать как своего рода замену службы ведения очередей сообщений Microsoft Message Queue (MSMQ). В последней версии служба Service Broker вошла в состав ядра программного обеспечения SQL Sender, поэтому больше не возникают проблемы, которые

раньше были обусловлены использованием двух или нескольких разньпс сервер-ных программньпс продуктов. Служба Service Broker обеспечивает асинхронный обмен данными между различными процессами или даже разными серверами.

В настоящем приложении показано, что возможности SQL Server выходят далеко за рамки исключительно обработки запросов. Разумеется, об этом можно было догадаться и раньше, изучая главы настоящей книги, посвященные описанию служб Reporting Services и Integration Services, а также машины Full-Text Search, но информация, приведенная в этом приложении, наглядно подтверждает, что программное обеспечение SQL Server, при всех своих широких возможностях, неуклонно продолжает свое дальнейшее развитие.

Служба Analysis Services

Выше в данной книге уже рассматривались некоторые сведения о том, чем отличаются базы данных, предназначенные для оперативной обработки транзакций (Online Transaction Processing - OLTP) и для оперативной аналитической обработки (Online Analytical Processing - OLAP). Причем основная часть этой книги посвящена описанию баз данных OLTP, поскольку они относятся к числу наиболее широко применяемых. Тем не менее вполне заслуживают внимания и базы данных OLAP. Мало того, значимость баз данньгх OLAP продолжает возрастать, поэтому не случайно поддержка аналитических приложений введена, начиная с версии SQL Server 7.0. После этого была дополнительно введена поддержка интеллектуального анализа данных, а в последней версии произошла полная модернизация средств OLAP, благодаря чему эти средства стали в большей степени соответствовать потребностям заказчиков и предоставили им гораздо большие возможности.

Несмотря на все вышесказанное, в этой книге описанию средств OLAP не посвящена отдельная глава. Такая глава имелась в предыдущих изданиях данной книги, но автор решил отказаться от описания средств аналитической обработки в настоящем издании. Дело в том, что объем сведений по теме, касающейся аналитической обработки, вырос до такой степени, что в книге недостаточно было предусмотреть для их изложения всего одну главу.

Поэтому автор решил не предпринимать попытку полного раскрытия этой темы, которая все равно могла оказаться незавершенной, а просто воспользоваться тем подходом, который уже не раз оправдался в прошлом, - представить краткие сведения по теме в наиболее компактной форме. В основе этого подхода лежат такие соображения, что важнее всего получить достаточно твердое представление о том, в чем заключаются возможности аналитической обработки, предусмотренные в SQL Server. На основе этих знаний можно уверенно приступать к изучению многочисленньпс книг, посвященных исключительно описанию службы Analysis Services (ведь объем материала по этой теме настолько велик, что на полных основаниях может занять от дельную книгу).

Краткое сравнение баз данных OLAP и OLTP

Задачи проектирования баз данных OLTP во многом отличаются от тех, которые приходится решать при проектировании баз данных OLAP, являющихся основой для большинства приложений Analysis Services. Прежде всего, в базах данных OLTP

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

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

Рассмотрим, в чем состоят различия между базами данных OLTP и OLAP, на примере проектов базы данных AdventureWorks, которая столь часто использовалась в этой книге, и сопровождающей ее базы данных AdventureWorksDW (в имени этой базы данных аббревиатура DW означает Data Warehouse - хранилище данных). База данных AdventureWorks спроектирована в целях ускорения ввода в оперативном режиме счетов-фактур, контроля за состоянием запасов и проведения других операций непосредственного доступа и обновления, а проект базы данных AdventureWorksDW в основном направлен на упрощение задачи формирования отчетов. Результатом реализации такого подхода становится то, что в базе данных AdventureWorksDW используется гораздо меньше таблиц. Степень нормализации базы данных AdventureWorksDW становится гораздо меньше, но модель представления всех данных намного упрощается, благодаря чему пользователь получает возможность легко понять структуру данных, беспрепятственно обращаться ко всем таблицам, необходимым для формирования отчетов, и получать требуемые данные гораздо быстрее, поскольку все они находятся в одном месте.

Чтобы ознакомиться с тем, как эти особенности отражаются на структуре таблиц, рассмотрим логические модели таблиц, связанных с таблицей Production. Product. Вначале рассмотрим ряд таблиц, представленных в базе данных AdventureWorks, как показано на рис. B.L

К этой подмодели относятся четырнадцать таблиц. Наличие такого большого количества таблиц не указывает на низкое качество модели (сам автор построил бы модель немного иначе, но проектные решения, принятые при создании базы данных AdventureWorks, вполне соответствуют теории). Это лишь еще раз подчеркивает, что проектирование рассматриваемой базы данных OLTP проводилось в целях реализации других требований по сравнению с базой данных OLAP. Итак, учитывая сказанное, рассмотрим версию базы данных OLAP, которую представляет собой AdventureWorksDW (рис. B.2V