Выражаемые, именованные и хранимые отношения
В соответствии с Коддом с банком данных ассоциируются три набора отношений: выражаемые, именованные и хранимые. Выражаемое отношение может быть определено через выражение языка доступа к данным (предполагается, что в этом языке поддерживаются операции, описанные в предыдущем разделе); у именованного отношения имеется известное пользователям имя; и хранимое отношение каким-то образом непосредственно представляется в физической памяти.
По этому поводу у меня имеется небольшое недовольство (если снова следовать правилу 20/20 для взгляда в прошлое). Кажется слегка неудачным способ использования Коддом термина хранимое отношение. Лично я предпочел бы разбить выражаемые отношения на два вида - базовые и производные отношения; я определил бы производное отношение как такое выражаемое отношение, значение которого в каждый момент времени производится из других выражаемых отношений в соответствии с некоторым реляционным выражением, а базовое отношение - как выражаемое отношение, не являющееся базовым в этом смысле. Другими словами, базовые отношения - "заданные"; порождаемые отношения - все остальные выражаемые отношения. И затем я бы четко прояснил, что базовые и хранимые отношения - это не обязательно одно и то же (см. рис. 1). Тем не менее, в статье фактически считается, что базовые и хранимые отношения являются одним и тем же (в основном потому, что в ней в ней вообще не упоминаются базовые отношения в качестве отдельной категории).
Рис. 1. Виды отношений
Верно, что базовые отношения представляют, по существу, то же самое, что и хранимые отношения в большинстве сегодняшних SQL-ориентированных продуктов. Другими словами, большинство людей считает, что в этих продуктах базовые отношения отображаются совершенно напрямую в физическую память. Но отсутствуют логические требования для такого простого отображения; на самом деле, различие между моделью и реализацией диктует то, что мы вообще ничего не говорим в модели о физической памяти. Более конкретно, степень различия между базовыми и хранимыми отношениями должна быть по крайней мере такой, как для представлений и базовых отношений; единственным логическим требованием является то, должна иметься возможность получения базовых отношений из тех, которые хранятся физически (а тогда могут быть получены и порождаемые отношения).
Однако, как я уже отмечал, в большинстве сегодняшних продуктов обеспечивается очень незначительная поддержка этой идеи; т.е. большинство сегодняшних продуктов обеспечивает намного меньшую независимость данных, чем теоретически возможно для реляционной модели. И именно поэтому мы впадаем в рассуждения о пресловутой денормализации. Конечно, иногда денормализация необходима (по соображениям эффективности), но ее следует производить на уровне физической памяти, а не на логическом уровне и не на уровне базовых отношений. Однако, поскольку в большинстве сегодняшних систем хранимые и базовые отношения воспринимаются, по существу, как одно и то же, этот простой вопрос приводит к большой путанице; кроме того, денормализация обычно обладает побочным эффектом порчи чистого во всех остальных отношениях логического проекта, с хорошо известными нежелательными последствиями.
Достаточно по поводу этих огорчений. Кодд продолжает: "Если интенсивность доступа к некоторому неименованному, но выражаемому отношению возрастает до значительного показателя, следует дать ему имя и тем самым включить в именованный набор." Другими словами, сделайте его представлением! Так что уже в 1969 г. Кодд говорил об идее представлений как "законсервированных запросов".
"Решения, связанные с тем, какие отношения принадлежат к именованному набору, основываются ... на логических нуждах сообщества пользователей, и, в частности, в потребности возрастающих инвестиций в программы, использующие именованные отношения, по причине предыдущего членства ... в именованном наборе." Здесь Кодд говорит о том, что представления являются механизмом для обеспечения логической независимости данных -- механизмом, который, в частности, гарантирует продолжение возможности выполнять программы при развитии базы данных. И он продолжает: "С другой стороны, решения, связанные с тем, какие отношения принадлежат хранимому набору, основываются ... на ... требованиях к производительности ... и изменениях, возникающих в этих [требованиях]." Здесь Кодд проводит очень четкую грань между логическим и физическим уровнями.
