Логическая модель данных предназначена для идеализированного представления ключевых логических сущностей данных и их взаимосвязей, независимых от реализации с помощью конкретного программного обеспечения и базы данных. В общем случае, это является третьей нормальной формой (см. Концепция: Нормализация), т.е. формой моделирования данных, которая минимизирует избыточность и обеспечивает отсутствие транзитивных зависимостей. Такая модель относится к представлению базы данных во время сбора данных, а не к приложениям, использующим данные, и их производительности. Заметьте, что Логическая модель данных считается частью Рабочий продукт: Модель данных, а не отдельным рабочим продуктом RUP. Однако, часто бывает важно определять Логические модели данных для:

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

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

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

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

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

Подробные шаги по разработке проекта физической базы данных состоят в следующем:

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

Определение доменов

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

Создание начальных элементов проекта физической базы данных

Проектировщик базы данных создает элементы Физической модели данных с помощью таблиц и столбцов таблиц, как это описано в разделе Рекомендации по рабочему продукту: Модель данных. 

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

В качестве альтернативы, проектировщик базы данных может начать разработку Физической модели данных с использования постоянных классов Модели проекта в качестве исходной точки для таблиц Физической модели данных.   Проектировщик базы данных моделирует постоянные классы и их атрибуты как  таблицы и столбцы соответственно.   Проектировщик базы данных должен также определить взаимосвязи между таблицами на основании связей между постоянными классами Модели проекта.   Описание того, как элементы Модели проекта и их взаимосвязи соотносятся элементами Модели данных и их взаимосвязями, предоставлено в разделе Рекомендации по рабочему продукту: Прямое проектирование реляционных баз данных.

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

Определение справочных таблиц.

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

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

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

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

Создание первичного ключа ограничений уникальности

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

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

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

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

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

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

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

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

Денормализация проекта базы данных для оптимизации производительности.

В случае реляционной Модели данных, начальное преобразование обычно является простым преобразованием класс-таблица. Если необходимо одновременно извлекать объекты из разных классов, то RDBMS применяет операцию, которая называется "соединение таблиц", для того чтобы получить строки, относящиеся к интересуемым объектам. При частом доступе к данным операции соединения могут потребовать слишком много вычислительных ресурсов. Для уменьшения затрат на обработку соединения часто применяется стандартный прием под названием "денормализация".

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

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

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

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

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

Оптимизация доступа к данным

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

Рассмотрим следующие принципы индексации:

• Столбец первичного ключа таблицы всегда должен быть индексированным. Столбцы первичного ключа часто используются как ключи поиска и для операций соединения.
• Таблицы, имеющие не более 100 строк и несколько столбцов, мало выигрывают от индексации. Малые таблицы легче хранить в кэше базы данных.
• Индексы также следует определить для часто исполняемых запросов или для запросов, которые должны быстро получать данные (в общем случае, любой поиск выполняется, пока человек может подождать). Индекс должен быть определен для каждого набора атрибутов, которые используются вместе как критерии поиска. Например, если система должна иметь возможность находить все Заказы, в которые включен определенный продукт, необходим индекс в таблице Строка заказа для столбца номера продукта.
• Обычно индексы необходимо определять только для столбцов, которые используются как идентификаторы, и которые имеют нечисловые данные, такие как сальдо счета, и не текстовую информацию, такую как комментарии к заказу. Значения столбца идентификатора обычно назначаются при создании объекта, а затем остаются неизменными на протяжении всего жизненного цикла объекта.
• Индексы над простыми числами (целыми и числовыми типами данных) намного проще и быстрее, чем индексы над строками. Даже большие объемы данных в запросе или большом соединении обрабатываются быстро.   Индексы над числовыми столбцами обычно занимают намного меньше пространства, чем индексы над символьными столбцами.

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

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

Многие базы данных предоставляют выбор типов индексов. Наиболее распространенными из них являются:

• Индексы B-tree - Наиболее часто используемый вид индекса, основанный на структуре данных сбалансированного дерева b-tree. Они полезны, когда значения ключа индекса случайно распределены и имеют сильное разнообразие. Однако, они имеют низкую производительность, когда индексированные данные уже упорядочены.
• Хэшированные индексы - Менее используемые индексы, значения ключа которых хешированы. Хеширование обеспечивает лучшую производительность, когда диапазон значений ключа индекса известен, уникален и относительно неизменен. Эта техника полагается на использование значения ключа для вычисления адреса интересуемых данных. Так как необходима предсказуемость, хэшированные индексы полезны только для таблиц поиска среднего размера, которые очень редко изменяются.

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

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

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

Определение параметров хранения

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

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

При планировании выделения дискового пространства и организации дисковых страниц в базе данных примите во внимание следующие факторы:

• Плотность информации в дисковых страницах
• расположение дисковых страниц на диске или среди многих дисков
• объем выделяемой для таблиц дисковой памяти

Эти факторы обсуждаются в следующих разделах.

Плотность дисковых страниц

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

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

• сильно динамические таблицы
• до некоторой степени динамические таблицы
• в основном статические таблицы

Сильно динамические таблицы должны располагаться на дисковых страницах, содержащих много пустого пространства (около 30%). Отчасти динамические таблицы должны располагаться на дисковых страницах, в которых меньше пустого пространства (около 15%). А наиболее статические таблицы должны располагаться на дисковых страницах, в которых совсем немного пустого пространства (около 5%). Индексы для таблиц должны быть распределены подобным образом.

Расположение дисковых страниц

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

• Никогда не помещайте на тот диск, который содержит операционную систему, ее временные файлы или устройства подкачки. Эти устройства и так достаточно загружены.
• Поместите данные, доступ к которым осуществляется одновременно, на разные диски, чтобы сбалансировать рабочую нагрузку. Некоторые системы поддерживают параллельные каналы ввода/вывода. В таком случае поместите данные на разные каналы.
• Поместите индексы и данные, которые они индексируют, на разные диски для распределения нагрузки.
• Подробная информация приведена в документации производителя базы данных.
• Используемые типы хранилища (например, RAID-5, RAID-10, SAN, NAS и присоединенные каналы) влияют на производительность базы данных. Следуйте рекомендациям поставщика хранилища по оптимизации производительности.

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

Распределение дискового пространства

С помощью механизма проектирования хранилища оцените количество объектов, которые должны быть сохранены. Объем дискового пространства, требуемый для хранения объектов, отличается для разных RDBMS.  При расчете дискового пространства учтите прирост объема из-за добавления данных.   Для того чтобы оценить объем дискового пространства для базы данных, сначала оцените объем, который требуется для каждой таблицы, а затем вычислите общий объем требуемого пространства для всех таблиц.   Из руководства администратора базы данных для данного продукта RDBMS определите точную формулу оценки размера.   Ниже приведено несколько общих шагов для оценки требуемого пространства для таблицы:

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

После определения требуемого объема для таблицы:

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

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

Проектирование хранимых процедур для реализации поведения класса в базе данных

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

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

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

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

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

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

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

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

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