Главная » Microsoft SQL Server, Базы данных » Проектирование физической схемы базы данных

0

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

?               Создание файлов базы данных.

?               Создание таблиц.

?               Создание первичных и внешних ключей.

?               Создание столбцов данных.

?               Создание ограничений, гарантирующих целостность данных.

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

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

?               Преобразование сложного логического проекта в более простые и гибкие структуры таблиц.

?               Преобразование составных первичных ключей в опирающиеся только на один столбец.

?               Преобразование бизнес-логики в ограничения и триггеры.

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

Варианты проектирования физической схемы

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

?               Логическая схема базы данных создается, а затем реализуется без оглядки на физическую схему.

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

?               Логическая схема базы данных создается при хорошем понимании требований бизнес- логики. Основываясь на логической модели, команда разработчиков создает физическую схему базы данных. Данный подход способен обеспечить создание быстрой и жизнеспособной схемы.

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

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

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

Корректировка модели данных

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

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

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

Вопросы производительности

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

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

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

Вопросы масштабируемости

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

?               Использование последовательного соглашения об именах.

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

?               Использование сценариев, а не Management Studio.

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

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

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

?               Документирование не только того, как работает процедура, но и почему она работает именно так.

Ответственный подход к денормализации

Забавно, но функция проверки орфографии в моей программе Microsoft Word предлагает заменять слово “денормализация” словом “деморализация”. Если речь вдет о реляционной транзакционной базе данных, то мне к этому нечего добавить.

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

.Дополнительная О нормализации см. в главе 2.

информация

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

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

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

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

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

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

Архитектура базы данных и то, какие таблицы для каких целей в ней использовать, являются движущей силой в принятии решения относительно денормализации части базы данных. Если база данных требует как OLTP, так и OLAP, то лучшим решением будет создание нескольких таблиц, которые дублируют данные для своих целей. Для OLTP нужны свои таблицы, отвечающие за поддержку данных, однако службе отчетности могут потребоваться аналогичные данные в собственной, расширенной таблице, из которой они будут извлекаться без необходимости привлечения множества объединений и блокировок. Здесь вся хитрость заключается в постоянном корректном заполнении денормализованных данных.

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

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии