Некоторые системы реляционных баз данных способны поддерживать согласованность денормализованных данных в некоторой степени (если я правильно понимаю, что вы имеете в виду).
В Oracle это называется materialized views, в SQL Server- indexed views.
По сути, это означает, что вы можете создать саморентифицированную денормализованную таблицу в результате запроса SQL и проиндексировать ее:
CREATE VIEW a_b
WITH SCHEMABINDING
AS
SELECT b.id AS id, b.value, b.a_id, a.property
FROM dbo.b b
JOIN dbo.a a
ON a.id = b.a_id
Полученное представлениеa_b, если бы это была реальная таблица, нарушило бы 2NF, поскольку property функционально зависит от a_id, который не является ключом-кандидатом.Однако система баз данных поддерживает эту функциональную зависимость, и вы можете создать составной индекс, скажем, для (value, property).
Даже MySQL и PostgreSQL, которые изначально не поддерживают материализованные представления, способны поддерживатькакие-то денормализованные таблицы.
Например, когда вы создаете индекс FULLTEXT для столбца или набора столбцов в MySQL, вы получаете два индекса одновременно: первый содержит по одной записи для каждогоотдельное слово в каждой записи (со ссылкой на исходную запись id), вторая содержит одну запись на каждое слово во всей таблице с общим количеством слов.Это позволяет быстро находить слова и упорядочивать их по релевантности.
Таблица общего количества слов, конечно, зависит от таблицы отдельных слов и, следовательно, нарушает 5NF, но, опять же, системы поддерживают эту зависимость.
Аналогичные действия выполняются для индексов GIN и GIST в PostgreSQL.
Конечно, нельзя поддерживать все возможные денормализации, это означает, что вы не можете материализовать и индексировать только любой запросв режиме реального времени: некоторые слишком дороги в обслуживании, некоторые теоретически возможны, но не реализованы в реальных системах и т. д.
Однако вы можете поддерживать их, используя собственную логику в триггерах, хранимых процедурах или чем-то еще, это точнодля чего они там.