Database Programming & Design

       

Практическая схема специальных значений


Во введении я выражал желание увидеть схему с двузначной логикой

и значениями по умолчанию, понятность и простота которой

уравновешивала бы уменьшение выразительной мощности. Поскольку

Дейт не дал нам такую схему, я кратко обрисую ее сам.

Прежде всего, я согласен с Дейтом в том, что по возможности нам

стоит устранить в своих базах данных атрибуты, допускающие

неопределенные значения. С некоторыми оговорками (которые здесь

не буду разъяснять) я согласен и с тем, что хорошим подходом

является расщепление типа сущности с подобным атрибутом на два

подтипа. В первом подтипе атрибут не сможет содержать

неопределенные значения, а во втором не будет самого этого

атрибута.

Во-вторых, я полагаю, что для идентификации специальных значений

следует зарезервировать одно или несколько значений из обычного

домена атрибута. Все что требуется, это одно значение, которое

означает, что "реальное значение отсутствует". Возможно,



потребуется различать случаи неприменимости, неизвестности и "то

или другое, не знаю точно что". В ответ на часто используемый

Дейтом аргумент, что имеется произвольное число различных типов

неопределенных значений и, следовательно, потребуется MVL с

произвольным числом истинностных значений, я заметил бы, что мне

кажется наивным полагать необходимость наличия формально

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

формулировки условия отсутствия значения на естественном языке. В

книге Atzeni и DeAntonellis "Relational Database Theory"

(Benjamin/Cummings, 1993) показано, что любое такое условие можно

свести к одному из упомянутых выше.

При возможности, следует ввести бизнес-правила, гарантирующие,

что выбираемое значение не будет омонимом (т.е. не будет

использоваться в разном смысле). Например, если на предприятии

действует правило, что размер счета не может быть нулевым, то

можно использовать нули в атрибуте размера счета для индикации

отсутствия реального значения.

Однако иногда это невозможно.
Если на предприятии допускаются

счета нулевого размера, то наличие в столбце значения

"$000,000,00" будет означать a) счет нулевого размера и b)

"реальное значение отсутствует". Чтобы разобраться с подобными

омонимами, требуются дополнительные расходы. Выходом из положения

является добавления флага, отличающего нулевые счета ото всех

остальных, или использование в качестве специального значения

менее критичного и очень редко используемого реального значения

(например, "$999,999,98"). В последнем случае мы не устраняем

расходы на различение омономов, но существенно их сокращаем. На

самом деле, этот вид стратегии удешевленного использования

омонимов использовался десятки лет.

Наконец, заметим, что стратегия избежания омонимов с

использованием некоторого значения для идентификации "отсутствия

реального значения", не значащего ничего больше, предоставляет ту

же выразительную мощность (и те же сложности), что схема Дейта со

специальными значениями. Собственно, стратегия состоит в том,

чтобы найти представление UNK внутри обычного домена, а не

заставлять производителей СУБД расширять этот домен.

Новая схема Дейта является альтернативой MVL с неправильно

определенной операцией сравнения по равенству, полным отсутствием

операций сравнения на больше и меньше, невозможностью получать

полную информацию из базы данных и существенным усложнением

написания даже простых запросов. Более того, теперь, когда мы

понимаем, как далека схема Дейта от реализации, видно, что наши

дебаты не имеют непосредственного отношения к практической

разработке и использованию баз данных. И проектировщики, и

пользователи будут продолжать работать при наличии ограничений,

свойственных применяемым диалектам SQL.

Консерваторы будут избегать использовать неопределенные значения

и MVL, осмотрительно остерегаясь сложности. Чтобы им помочь, я

кратко изложил практический подход к управлению отсутствующей

информации, который может быть использован при наличии

сегодняшних продуктов баз данных. Этот подход не претендует на

оригинальность и лишь немного расширяет существующую практику.

Более рисковые пользователи будут использовать неопределенные

значения и, возможно, иногда им придется обжигаться. Но

постепенно у них составится понимание сути неопределенных

значений и MVL, которое невозможно получить при чтении книг.


Содержание раздела