Нормализация
Логическая схема базы данных, включающая таблицы и связи между ними, является основой оптимизации реляционной базы данных. Хорошая логическая схема базы данных может обеспечить фундамент для оптимальной производительности базы данных и приложения. Плохая логическая схема базы данных может снизить производительность всей системы.
Нормализация логической схемы базы данных включает использование формальных методов для разделения данных на несколько связанных таблиц. Наличие довольно большого количества узких таблиц с небольшим количеством столбцов является характерной особенностью нормализованной базы данных. Наличие небольшого количества широких таблиц с большим количеством столбцов является признаком ненормализованной базы данных.
Рациональная нормализация часто улучшает производительность. При возможности использования полезных индексов SQL Server оптимизатор запросов является действенным средством в выборе быстрых, эффективных соединений между таблицами.
Ниже приведены некоторые из преимуществ нормализации:
более быстрая сортировка и создание индексов;
большее количество кластеризованных индексов. Дополнительные сведения см. в разделе Правила проектирования кластеризованного индекса;
более узкие и компактные индексы;
меньшее количество индексов в таблице. Это улучшает производительность инструкций INSERT, UPDATE и DELETE;
меньшее количество значений NULL и более низкая вероятность несогласованности. Это повышает компактность базы данных.
При повышении нормализации количество и сложность соединений, необходимых для получения данных, также возрастают. Слишком большое количество сложных реляционных соединений между слишком большим количеством таблиц может снизить производительность. Рациональная нормализация часто включает несколько регулярно выполняемых запросов, которые используют соединения, включающие более четырех таблиц.
Иногда логическая схема базы данных уже зафиксирована, и полное повторное проектирование не реально. Однако даже в этом случае есть возможность выборочно нормализовать большие таблицы в несколько более мелких. Если доступ к базе данных возможен посредством хранимых процедур, это изменение схемы может быть осуществлено без нанесения ущерба приложениям. В противном случае можно создать представление, которое скроет изменение схемы от приложений.
Достижение наилучшей схемы базы данных
В теории проектирования реляционных баз данных правила нормализации указывают определенные атрибуты, которые должны присутствовать или отсутствовать в хорошо спроектированной базе данных. Полное обсуждение правил нормализации выходит за рамки этого подраздела. Однако есть несколько правил, которые могут быть полезными в достижении безупречной структуры базы данных.
Таблица должна иметь идентификатор.
Основным правилом теории проектирования баз данных является то, что каждая таблица должна иметь уникальный идентификатор строки, столбца или набора столбцов, используемый для выделения отдельной записи из всех остальных записей в таблице. Каждая таблица должна иметь идентификатор столбца, никакие две записи не должны иметь одинаковое значение идентификатора. Столбец или столбцы, выступающие в качестве уникального идентификатора строки для таблицы, являются первичным ключом этой таблицы. В базе данных База данных AdventureWorks2008R2 каждая таблица содержит столбец идентификаторов, являющийся столбцом первичного ключа. Например, столбец VendorID является первичным ключом для таблицы Purchasing.Vendor.
В таблице должны храниться данные только для одного типа сущности.
Попытка хранить в таблице слишком много данных может снизить эффективность и надежность управления данными в таблице. В образце базы данных База данных AdventureWorks2008R2 сведения о заказах на продажу и заказчиках хранятся в отдельных таблицах. Хотя можно составить столбцы, содержащие сведения как о заказах на продажу, так и о заказчиках, в одной таблице, эта структура может привести к возникновению нескольких проблем. Сведения о заказчике, его название и адрес должны быть добавлены и храниться отдельно для каждого заказа на продажу. Это ведет к использованию дополнительного места хранения в базе данных. При изменении адреса заказчика это изменение должно быть выполнено для каждого заказа на продажу. Кроме того, если последний заказ на продажу заказчика удаляется из таблицы Sales.SalesOrderHeader, сведения об этом заказчике теряются.
В таблице следует избегать наличия столбцов, разрешающих значения NULL.
Таблицы могут содержать столбцы, в которых разрешены значения NULL. Значение NULL означает отсутствие значения. Хотя в отдельных случаях разрешение значений NULL может быть полезным, следует использовать их ограниченно. Использование значений NULL требует дополнительного управления, что увеличивает сложность операций с данными. Если в таблице имеется несколько столбцов со значениями NULL и несколько строк со значениями NULL в этих столбцах, следует рассмотреть помещение этих столбцов в другую таблицу со ссылкой на первичную. Хранение данных в двух отдельных таблицах обеспечивает простую структуру первичной таблицы и возможность контролирования тех случаев, когда хранение этих данных необходимо.
В таблице не должно содержаться повторяющихся значений или столбцов.
Для определенного элемента базы данных в таблице не должно содержаться списка значений для конкретного набора данных. Например, продукт в базе данных База данных AdventureWorks2008R2 может закупаться у нескольких поставщиков. Если в таблице Production.Product содержится столбец для имени поставщика, возникает проблема. Одним из решений будет хранение имен всех поставщиков в столбце. Однако это осложняет просмотр списка определенных поставщиков. Другим решением является изменение структуры таблицы для добавления другого столбца для имени второго поставщика. Однако это позволит иметь только двух поставщиков. Если у книги имеется три поставщика, в таблицу придется добавить еще один столбец.
При необходимости хранения списка значений в одном столбце или при наличии нескольких столбцов для одного набора данных, например для TelephoneNumber1 и TelephoneNumber2, необходимо рассмотреть возможность помещения повторных данных в другую таблицу со ссылкой на главную. В базе данных База данных AdventureWorks2008R2 имеется таблица Production.Product, содержащая сведения о продуктах, таблица Purchasing.Vendor, содержащая сведения о поставщиках, и третья таблица — Purchasing.ProductVendor. В этой третьей таблице хранятся только значения идентификаторов продуктов и идентификаторов поставщиков этих продуктов. Эта структура обеспечивает наличие нескольких поставщиков продуктов без изменения названий таблиц и без выделения неиспользуемого места хранения для продуктов с одним поставщиком.
См. также