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

В этой лекции будет дана краткая вводная информация о версиях Microsoft Windows 2000 и SQL Server, которые вы можете выбрать для инсталляции. И наконец, вы получите сведения о типах внешних, интерфейсных (front-end) приложений для доступа к SQL Server, которые ваша фирма может приобрести или создать, а также о том, как архитектура приложений может влиять на перспективы масштабирования и производительности вашей системы.

Системные требования

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

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

Системное приложение

Что хорошего в базе данных SQL Server без приложения? Если не рассматривать случай, когда каждый работник в вашей фирме является специалистом в SQL и наслаждается составлением сложных запросов и просмотром данных в табличной форме, то пользы от нее немного. Приложение облегчает применение SQL Server. Некоторые приложения явно показывают, что вы работаете с базой данных, а некоторые – полностью скрывают это. В любом случае, важно спроектировать приложение так, чтобы пользователи могли получать необходимое им обслуживание с комфортом и своевременно. Во многих случаях пользователи бывают разочарованы медленными, неэффективными приложениями. В конце концов, если приложение не будет удовлетворять требованиям потребителей, они могут найти себе другую фирму, обеспечивающую более качественное обслуживание.

Приложения могут быть весьма разнообразными по выполняемым функциям. Можно обобщенно считать, что имеются три основные функции приложений: системы оперативной обработки транзакций ( OLTP, on-line transaction processing ), системы поддержки принятия решений ( DSS, decision support system ) и системы пакетной обработки данных ( batch processing ). Эти функции имеют различные требования и могут применять совершенно разные типы приложений.

OLTP (системы оперативной обработки транзакций)

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

• Онлайновые продажи. Этот вид систем OLTP получил широкое распространение из-за быстрого роста Интернет-коммерции. Покупая товары через Интернет, пользователям часто приходится терпеть задержки при передаче, доставке и обработке данных. Минимизируя длительность доступа к базе данных, вы уменьшаете общую длительность транзакций.
• Продажи в обычных магазинах. Когда кассир в магазине пробивает вашу кредитную карточку, происходит доступ к базе данных. Прежде чем запрос достигнет базы данных, транзакция пройдет через множество компьютеров.
• Системы для бизнеса. У каждой фирмы имеется какое-нибудь приложение для доступа к базам данных. Это может быть ваша платежная система, система для закупок, база данных кадровой службы, система для учета имущества или еще какая-нибудь другая система. Такие приложения могут быть созданы как приложения для внутренней сети, реализованы на языках программирования вроде C++ или Microsoft Visual Basic, или при помощи инструментального средства – языка четвертого поколения (4GL). В любом случае, в конечном итоге, данные поступают из базы данных.

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

DSS (системы поддержки принятия решений)

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

• Кто является основными продавцами в том или ином районе? Какие товары они преимущественно продают?
• В какое время года лучше всего продаются те или иные товары?
• Как влияло понижение цены на продажи того или иного товара?
• Каковы средние размеры комиссионных для продавцов в том или ином районе?

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

Системы пакетной обработки данных

Системы пакетной обработки данных обрабатывают неоперативные (offline) задания обработки данных, не имеющие никаких компонент для работы с конечными пользователями. Вот типичные примеры таких систем:

• Ежедневное обновление данных. Для некоторых систем поддержки принятия решений требуется еженочная загрузка новых данных, и эта работа часто выполняется автоматически при помощи заданий пакетной обработки данных.
• Преобразование данных. Эта задача похожа на обновление данных, но сопровождается преобразованием данных.
• Очистка данных. При выполнении этой задачи происходит, например, удаление из базы данных дублирующихся записей.
• Автономное выписывание счетов. Эта задача может заключаться в еженочном выписывании счетов потребителям.

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