Реферат: MS SQL Server 6.5
Есть и другие методологии, в частности Объектно-Ролевое моделирование, которое позволяет описывать предметную область на более абстрактном уровне, чем моделирование "Сущность-Связь", по крайней мере базовый вариант последней. Объектно-Ролевое моделирование реализовано в CASE-инструменте InfoModeler фирмы Asymetrix. Применение S-Designor и InfoModeler рассмотрено в докладе "Проектирования структур баз данных с использованием CASE-инструментов S-Designor и InfoModeler".
Нормализация
В процессе построения логической модели осуществляется также нормализация, т.е. построенная модель удовлетворяет требованиям трех уровней нормализации:
1. Первая нормальная форма - отсутствие многозначных полей.
-
Вторая нормальная форма - каждое неключевое поле в таблице должно зависеть от всего первичного ключа, а не от какой-либо его части.
3. Третья нормальная форма - неключевое поле не должно зависеть от другого неключевого поля.
В сущности, нормализация приводит к большему количеству более узких таблиц в логической модели. Соблюдение правил нормализации снижает избыточность данных и, соответственно, сложность их обновления и занимаемый ими объем на носителе. Связи между полученными таблицами разрешаются через построение сложных соединяющих запросов. Оптимизатор запросов SQL Server умеет строить эффективные планы выполнения запросов, связывающих высоко нормализованные таблицы. Этому способствует также построение индексов, основанное на связи первичных и внешних ключей таблиц.
CASE-инструменты, как правило, строят логическую модель в третьей нормальной форме.
Денормализация
Однако зачастую, разумная, именно разумная, сознательная денормализация логической структуры может повысить скорость выполнения определенных запросов. Если проектирование нормализованной структуры идет, так сказать, "от данных", то денормализация идет "от процессов". То есть, денормализация должна быть основана на знании того, какие действия будут осуществляться с данными при работе с ними клиентских приложений. Вот несколько практических советов по денормализации:
• Если спроектированная база данных требует связывания в одном запросе 4-х и более таблиц, стоит ввести избыточность, добавляя поля в таблицы или целые таблицы.
• Замените длинные ключи на искусственно введенные короткие ключи и текстовые поля на символьные строки ограниченной длины.
• Если определенная группа запросов затрагивает только часть полей широкой таблицы, ее можно разбить на несколько более узких таблиц, продублировав в них первичный ключ исходной таблицы. Это может уменьшить количество операций ввода-вывода и облегчить одновременную работу разных пользователей.
• Если определенная группа запросов затрагивает только часть строк таблицы большого объема, ее можно разбить по горизонтали на несколько таблиц, особенно если определенные группы пользователей обращаются к разным горизонтальным подмножествам таблицы.
Противоречия логического проектирования
Нормализация и денормализация - две диалектически противоречивые стратегии, которые необходимо применять при проектировании логической структуры. И это не единственное противоречие в этом процессе. Например - использование типов данных с переменной длиной приводит, с одной стороны, к сокращению занимаемого дискового пространства, к меньшему количеству операций чтения и, таким образом, к сокращению времени на чтение таблицы. С другой стороны, обновление таких строк происходит путем удаления старой и вставки новой, в то время, как строки с полями фиксированной длины могут обновляться "на месте", что значительно быстрее. Еще один пример - использование большого числа индексов сокращает время выполнения запросов, соединяющих несколько таблиц и сортирующих полученные строки. Но в то же время, индексы замедляют операцию вставки новых записей.
Приложения по обработке данных можно условно разделить на два класса:
• Системы оперативной обработки транзакций, характеризующиеся большой интенсивностью вставки и обновления записей.
• Системы поддержки принятия решений, характеризующиеся сложной обработкой больших объемов данных. Эти приложения, как правило, не обновляют данные, но производят различные суммирования, сортировки и связывают данные из многочисленных таблиц.
Поняв, к какому классу относится ваше приложение, можно делать выбор из противоречивых альтернатив при проектировании логической структуры. Правда, часто приложения должны сочетать качества как одной, так и другой системы, так что приходится находить компромиссы. В этом случае может выручить разделение приложения на две подсистемы, каждая из которых функционирует на своем SQL Server'е, и обеспечение информационной связи подсистем при помощи тиражирования данных.
Проектирование путей доступа
Когда создана структура базы данных, можно проектировать запросы, при помощи которых клиентские приложения будут манипулировать данными на сервере, осуществляя операции выборки, вставки, изменения и удаления данных. Каждый запрос характеризуется определенным путем доступа к данным. В понятие пути доступа входит:
• структура таблицы, к которой обращается запрос;
• поля, по которым происходит поиск;
• индексы, которые можно использовать для ускорения поиска;
• состав полей, которые обновляются в процессе выполнения запроса.
Цель проектирования оптимальных путей доступа - минимизация количества операций чтения/записи при выполнении клиентских запросов. Основа для этого должна быть заложена на этапе проектирования структуры базы данных.
Оптимизация путей доступа
Главный вопрос в оптимизации путей доступа - использование индексов. Если некий запрос выбирает строки в таблице по полю "field1", то при отсутствии индекса по этому полю сервер будет сканировать всю таблицу, что может быть очень "дорого" в терминах операций чтения. Если по полю "field1" построен индекс, то количество операций чтения может сократиться в несколько тысяч раз. Индексы существенны также при операциях соединения таблиц (JOIN) и операциях сортировки.