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

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

4. Примеры проектирования баз данных различных бизнес приложений

   1. Общие замечания

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

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

2. В примерах реализованы этапы только инфологического и даталогического проектирования.

3. Разработка информационных моделей осуществляется в соответствии с методологией IDEF1X.

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

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

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

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

8. В результате проектирования в точном соответствии методологии IDEF1X получаемые схемы отношений удовлетворяют 4НФ; дополнительная нормализация отношений на этапе даталогического проектирования в примерах не рассматривается.

9. В примерах приводится описание внутренней схемы БД средствами языка описания данных, в качестве которого в реляционных СУБД используется подмножество языка SQL. Подробное описание языка можно найти в документации используемых на практике СУБД, а также в [1, 16]. В примерах приводятся фрагменты определения БД: предложения CREATE TABLE (создать таблицу) и ALTER TABLE (изменить таблицу).

10. В примерах приводятся предложения SQL, соответствующие стандарту SQL/92. Особенности языка, специфические для каждой конкретной СУБД (например, задание альтернативных ключей, построение уникальных индексов), в примерах не рассматриваются.

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