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

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

Закупочная деятельность.

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

Товарно-материальные запасы.

Кредиторская задолженность.

Главная книга.

Управление денежными средствами.

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

Способы выделения компонентов

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

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

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

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

Для этого необходимо, в частности, учесть перечисленные ниже требования.

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

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

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

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

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

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

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

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

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

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

Денормализация

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

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

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

Иногда благодаря включению в таблицу лишь одного денормализованного столбца (или нескольких таких столбцов) удается избежать необходимости применения соединений для выборки информации или значительно сократить количество таких соединений. Нужно научиться распознавать подобные ситуации; фактически они возникают довольно часто. Самому автору встречались такие ситуации, в которых в результате добавления одного столбца к часто применяемой базовой таблице появилась возможность перейти от использования соединения девяти таблиц к соединению всего лишь трех таблиц и таким образом сократить продолжительность вьшолнения запроса примерно на 90%.

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