20. Реляционная модель данных: сравнение нормализованных и ненормализованных моделей

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

Адекватность базы данных предметной области 1НФ,2НФ - ХУЖЕ (-) 3НФ - ЛУЧШЕ (+)

Легкость разработки и сопровождения базы данных 1НФ,2НФ - СЛОЖНЕЕ (-) 3НФ - ЛЕГЧЕ (+)

Скорость выполнения вставки, обновления, удаления 1НФ,2НФ - МЕДЛЕННЕЕ (-) 3НФ - БЫСТРЕЕ (+)

Скорость выполнения выборки данных 1НФ,2НФ - БЫСТРЕЕ (+) 3НФ - МЕДЛЕННЕЕ (-)

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

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

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

21. Целостность реляционных данных: Null-значения, потенциальные ключи, простой ключ, составной ключ, первичный ключ, альтернативный ключ

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

<имя атрибута> IS NULL < имя атрибута > IS NOT NULL

Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса.

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

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

1. Свойством уникальности - в отношении не может быть двух различных кортежей, с одинаковым значением K. 2. Свойством неизбыточности - никакое подмножество в K не обладает свойством уникальности.

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

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