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

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

L Определяется имя файла, предназначенного для хранения данных.

2. Файл создается и копируется в каталог, который отведен для его размещения.

3. Уточненное имя файла (которое включает имя каталога) сохраняется в формате varchar (255) (этот формат выбран с учетом того, что максимально допустимая длина имени файла, которое включает имя каталога, в операционной системе Windows составляет 255) наряду с остальной частью данных, относящихся к той строке, где должны находиться данные типа BLOB.

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

5. После этого выполняется выборка данных из файловой системы.

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

Данные типа BLOB, предназначенные для хранения в базе данных, никогда не превышают по размерам некоторой достаточно малой величины (например, всегда остаются меньше 8 Кбайт).

Данные имеют текстовый или иной формат, для которого в службе MS Search предусмотрен фильтр, и есть необходимость применять к этим данным средства полнотекстового поиска.

Если данные типа BLOB никогда не превышают по размерам 8 Кбайт, то остается возможность поместить эти данные на одной странице данных. В результате этого издержки, связанные с обработкой данных типа BLOB, существенно снижаются. Безусловно, и в этом случае подход, основанный на использовании файловой системы, со значительной вероятностью по-прежнему остается более быстродействующим, но его преимущество в быстродействии настолько резко обесценивается, что теряется смысл в использовании этого подхода. Тем не менее, если в указанных обсто5ггельствах наиболее важным требованием является быстродействие, то не следует сразу же отказываться от варианта, предусматривающего хранение данных в файловой системе. Необходимо провести эксперименты и выбрать тот или иной подход на основе полученных результатов.

С другой стороны, если требуется обеспечить выполнение полнотекстового поиска, то, по-видимому, следует оказаться от других подходов и перейти к использованию способа хранения в СУБД SQL Server крупных блоков текста в виде данных типа text (этот тип данных как раз и относится к одному из типов данных BLOB). Если текст представлен в двоичном формате, для которого предусмотрен фильтр MS Search (при желании достаточно квалифицированный разработчик может самостоятельно написать программу фильтра для неподдерживаемого формата файла), то можно сохранить этот текст с применением типа данньгх image, после чего служба MS Search автоматически создаст для него полнотекстовый индекс с помощью соответствующего фильтра. Из сказанного выше не следует, что невозможно организовать полнотекстовый поиск в текстовом файле, но в рассматриваемом сл)ае данные столбцов типа BLOB хранятся в файловой системе, а относящиеся к той же таблице данные столбцов с типами, отличными от BLOB, хранятся в базе данных, поэтому приходится применять значительно больший объем кода для сохранения связей между данными одних и тех же строк. Кроме того, повышается вероятность того, что в программном обеспечении промеж)пгочного уровня придется учитывать необходимость использования сервера индекса (который является одним из компонентов, обеспечивающих поддержку полнотекстового поиска в СУБД SQL Server).

Если приходится заниматься внедрением средств активной рассылки с помощью push-технологии и возникает задача организовать полнотекстовый поиск по данным, представленным в файловой системе, то можно попытаться обеспечить непосредственный доступ к серверу индекса с помощью запросов. В СУБД SQL Server предусмотрена возможность применять запросы к удаленным источникам данных, с помощью которых, в частности, может быть получен доступ к любому источнику данных OLEDB. В составе службы MS Search имеется провайдер OLEDB, поэтому данная служба может использоваться на целевом компьютере в качестве связанного сервера или предоставлять доступ к данным с помощью функции OPENQUERY. Но такая организация работы имеет свой недостаток, обусловленный тем, что выполнение запроса сервера индекса применительно к серверу индекса, который не находится на том же физическом компьютере, что и сервер SQL Server, фактически неосуществимо. Единственный способ решения этой проблемы состоит в том, чтобы сервер индекса был развернут на том же компьютере, что и сервер SQL Server, т.е. локально по отношению к нему, но при этом была предусмотрена такая конфигурация, чтобы файлы каталогов сервера индекса хранились на другом компьютере. Но при такой организации работы приходится сталкиваться с тем, что в процессе каталогизации данных происходит весьма интенсивный обмен данными по сети. Обнаруживается также такой недостаток, что весь объем работы по каталогизации сосредоточивается на одном компьютере (иными словами, добиться высокой степени масштабируемости невозможно).

На этом описание первого способа организации хранения данных BLOB в файловой системе завершается (напомним, что выше в данной книге речь шла о двух способах). Второй способ основан на новой архитектуре сборок .NET, которая входит в состав программного обеспечения SQL Server 2005. В настоящей книге фактически еще не затрагивалась тема интеграции с инфраструктурой .NET, поэтол1у ниже приведено краткое описание связанных с этим вопросов.

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

После появления средств интеграции с общей средой вьшолнения (Common Language Runtime- CLR) появились возможности создания гораздо более сложных пользовательских функций по сравнению с тем, что было возможно раньше. При этом одним из наиболее важных достижений является появление средств определения табличных функций (функций, возвращающих данные в виде таблицы), которые позволяют осуществлять выборку данных почти из всех основных источников данньгх. Действительно, в главе 14 будет представлен пример, который показывает, как обеспечить просмотр файлов, содержащихся в каталоге, и возврат данных этих файлов с помощью табличной функции, но с таким же успехом можно было бы предусмотреть возврат столбца varbinary (max), содержащего данные, полученные из файлов. При использовании такой модели достутга все операции доступа к файлу осуществляются в условиях применения сетевого контекста безопасности, который определен как предназначенный для эксплуатируемой сборки, но сами операции доступа выполняются исключительно в составе табличной функции.

Подкатегории

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

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

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

Документ имеет множество атрибутов, которые являются общими для официального док)ТУ1ента любого типа. Примеры таких атрибутов перечислены ниже.

Название.

Автор.

Дата создания.

Дата последнего изменения.

Место хранения.