6NF и исторические атрибутные данные

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

Скажем, например, мы берем этот пример из @PerformanceDBA, но со следующим дополнительным требованием:

Нам нужно хранить исторические данные для всех наших продуктов, мы должны иметь возможность просто ввести дату и получить снимок атрибутов продукта в это конкретное время.

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

Вещи, которые я рассматриваю

  • Добавьте столбец временной метки «changedate» в каждую таблицу атрибутов (это приведет к довольно сложному запросу с подзапросом и объединением для каждой таблицы атрибутов)
  • Создайте отдельную * таблицу истории для каждой таблицы атрибутов (может привести к огромному количеству таблиц, поскольку у нас около 70 атрибутов, распределенных по 20 типам продуктов)
  • Дополнительно: добавьте индексированный столбец «текущий» в каждую таблицу атрибутов, чтобы ускорить просмотр 5NF.

Любая помощь приветствуется!

Изменить: я знаю концепцию временных баз данных, но проблема в том, что для движка базы данных, с которым я работаю (postgresql), временное расширение еще не полностью реализовано. Есть какие-нибудь советы о том, как этого добиться без временных баз данных?


database relational-database database-design database-normalization
person ChrisR    schedule 23.01.2012    source источник
comment
Просто чтобы вас предупредить - я пошел по пути НЕ имея таблиц истории и использовал from и to date в каждой строке моих объектов. Это была самая большая ошибка, которую я совершил, и она превратила проект в кошмар. Потребовалось руководство человека, которого вы упомянули, PerformanceDBA, чтобы я действительно понял, что такое база данных (то есть не просто ведро для объектов). С тех пор я переписал проект, используя более традиционный подход (таблицы / представления истории), и он стал лучше во всех отношениях. Ладно, не так уж и много аргументов, но для того, чтобы вдаваться в подробности, потребуется огромное количество документации.   -  person Mark    schedule 07.03.2012
comment
Это сообщение, которое побудило меня изменить свой взгляд на базы данных в целом (с точки зрения разработчиков программного обеспечения, с точки зрения администратора баз данных): - stackoverflow.com/questions/4491173/. Я не говорю, что делать то, что было предложено, неправильно (использовать from и to и нет таблицы истории), но для меня это создало большой беспорядок, и я никогда больше не пойду по этому пути.   -  person Mark    schedule 07.03.2012

Ответы (1)


arrow_upward
9
arrow_downward

Недавно утвержденный стандарт SQL: 2011 включает функции, которые позволяют лучше справляться с подобными проблемами, чем вы могли когда-либо прежде.

Не то чтобы вы могли делать все, что хотели бы, на временной арене, но то, что было введено, действительно является довольно значительным улучшением.

Хорошая презентация об этом находится на http://metadata-standards.org/Document-library/Documents-by-number/WG2-N1501-N1550/WG2_N1536_koa046-Temporal-features-in-SQL-standard.pdf.

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

На сайте www.linkedin.com также есть дискуссионная группа «Временные данные», посвященная именно вашей теме.

ИЗМЕНИТЬ, пытаясь обратиться к "Любому совету о том, как достичь этого без временных баз данных?"

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

Итак, добавьте ОБЕИ столбец даты / времени начала и окончания. НЕ ДЕЛАЙТЕ НИ ОДИН ИЗ НИХ ОБУЧАЕМЫМИ. Новый стандарт требует этого из-за его временных характеристик. Если конечный MIT (момент времени) все еще неизвестен, используйте наивысшее значение применимого типа времени, например 9999-12-31.

Вам НЕ НУЖНО «создавать отдельные таблицы истории для каждого атрибута». Точно так же можно иметь «таблицу единой сущности», которая хранит «историю возникновения всей сущности». Обратной стороной является то, что будет сложно запросить, когда произошло ФАКТИЧЕСКОЕ изменение какого-либо конкретного атрибута (потому что вы получаете новые исторические строки для любого изменения любого атрибута, возможно, копируя одно и то же значение атрибута для большинства атрибутов). «Единая таблица», вероятно, будет активным потребителем пространства, «отдельная история для каждого атрибута» может быть нетерпеливым потребителем запроса времени ЦП. Это будет действие по уравновешиванию, и то, где именно находится баланс, зависит от вашей конкретной ситуации.

Не «добавляйте индексированный« текущий »столбец» в свои таблицы. Во-первых, они не помогут вам перейти на новые функции, когда они есть в вашем движке, а во-вторых, столбцы типа «да / нет» - очень плохие дискриминаторы и, следовательно, очень плохие кандидаты для индексации. Я бы предпочел добавить ваше начало или конец в индекс, можно ожидать, что они дадут вам такие же выигрыши для «текущих» строк и лучшую победу для нетекущих строк, когда вам нужно запросить эти .

Что касается обеспечения соблюдения ограничений базы данных, таких как отсутствие перекрытия периодов времени во временных ключах и включение периодов времени во временный RI, ну, вы полностью предоставлены сами. Напишите нужный код в триггерах, SPROC или коде приложения в порядке убывания предпочтения.

Было ли это более полезным?

person Erwin Smout    schedule 23.01.2012
comment
Спасибо, теперь я узнал о временном расширении для postgresql (github.com/jeff -davis / PostgreSQL-Temporal / downloads), который, кажется, именно то, что я ищу. Еще несколько практических примеров могут помочь. - person ChrisR; 24.01.2012