(осуществить денормализацию). Это позволяет значительно сократить количество таблиц, применяемых для хранения данных, и ускорить работу с ними.

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

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

Повышение масштабируемости с помощью секционирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструментальные средства формирования ER-диаграмм СУБД SQL Server

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

Приступим к созданию первой диаграммы, рассматриваемой в качестве примера. Для этого необходимо щелкнуть правой кнопкой мыши на узле Diagrams, находящемся под узлом базы данных AdventureWorks, и выбрать опцию New Database Diagram.

Как было указано в главе 4, может появиться диалоговое окно с предостережением (если предпринимается первая попытка создать диаграмму), согласно которому некоторые объекты, необходимые для обеспечения построения диаграмм, отсутствуют в базе данных, и с вопросом, следует ли создать эти объекты; в таком, случае выберите положительный ответ, Yes.