ГЛАВА 10 Cxef дэмных

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

Индексы

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

Если поле или поля, составляющие внешний ключ, входят также в первичный ключ, но не составляют его полностью, я создаю в таблице дополнительный индекс, включая в него все поля внешнего ключа. Например, в таблице Orderltems (Заказанные продукты) существует первичный ключ, в который входят поля OrderlD, ItemlD. И хотя индекс, определенный на полях первичного ключа, можно использовать для соединения этой таблицы с главной таблицей Orders (я считаю, что так можно получить большинство результатов, нужных пользователям), на всякий случай лучше создать в таблице Orderltems дополнительный индекс на поле OrderlD.

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

ЧАСТЬ 2 вттотш систем баз щшщтх.

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

Максимальное число индексов для определяется тем,

насколько часто обновляется эта таблица - ведь дополнительная нагрузка, связанная с поддержкой индекса, возникает только при добавлении и обновлении данных или обновлении полей индекса Например, для такой таблицы как Orders (Заказы), обновляемой достаточно часто, я не рекомендую создавать более 10 или 15 индексов, включая индексы, используемые для соединения и

ный ключ. А вот в таблице Products (Продукты) индексов может быть

поскольку она обновляется сравнительно редко, но но используется в системе. Как решая вопрос о числе индек-

сов, следует исходить из того, как используются данные в

Представления и запросы

в Access и SQL Server можно сохранять SQL-операторы SELECT. Эти сохраненные операторы называются представлениями в SQL Server и запросами в Access. Я буду называть их запросами, независимо от того, какой механизм баз данных используется, поскольку этот термин шире распространен. В большинстве случаев си-

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

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

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

ГЛАВА 10 Cf-ema Ьеш данных

в связях один тогим . как например Orders rftems. Но в

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

базы данных соответствующие запросы.

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

Иногда для одной сущности нужно использовать несколько разных запросов. Например, чтобы найти заказ, относящийся к определенной дате (используется атрибут U/ucriJaic). или заказ, сделанный определенным клиентом (атрибут или заказ по регист-

номеру (атрибут Для поиска заказов по каждо-

му из этих параметров нужно составлять параметрический

запрос.

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

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

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

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

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

В зависимости от как устроены рабочие процессы в проекти-

руемой системе, вам может включить в схему базы дан-

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