моделирование и нормализация темпоральной базы данных

Question

Должны ли даты для временной базы данных храниться в одной или двух таблицах?Если это не нарушает нормализацию?

PERSON1 DATE11 DATE21 INFO11 INFO21 DEPRECATED
PERSON2 DATE21 DATE22 INFO21 INFO22 CURRENT
PERSON1 DATE31 DATE32 INFO31 INFO32 CURRENT

Столбцы DATE1 и DATE2 указывают, что INFO1 и INFO2 верны для периода между DATE1 и DATE2.Если ДАТА < СЕГОДНЯ, факты устарели и больше не должны отображаться в пользовательском интерфейсе, но их не следует удалять в исторических целях.Например, INFO11 и INFO21 устарели.

Должен ли я разделить эту таблицу?Должен ли я хранить состояние (устаревшее или текущее) в таблице?

Чтобы уточнить вопрос, «Устаревший» — это термин, используемый бизнесом. Если вы предпочитаете «неактуальный», проблема не семантическая, речь идет не о SQL-запросах, я просто хочу знать, какой дизайн нарушает или лучше всего соответствует правилам нормализации. (Я знаю, что нормализация не всегда является правильным решением, но это тоже не мой вопрос).

Answer 1

«Я хочу знать, какой дизайн нарушает правила нормализации»

Зависит от того, какой набор правил нормализации вы хотите использовать.

Первое и наиболее вероятное нарушение нормальных форм, причем в Книга даты это нарушение первый НФ, — это ваши даты окончания в строках, содержащих «текущую» информацию (что абстрагирует возможность получения информации, датированной будущим временем):вы нарушите 1NF, если сделаете этот атрибут обнуляемым.

Нарушения BCNF очевидно, может произойти в результате вашего выбора ключей (как и в случае с нетемпоральными проектами баз данных - временной аспект здесь не имеет значения).По поводу "выбора ключей":если вы используете отдельные даты начала и окончания (и SQL не оставляет вам другого выбора), то, скорее всего, вам следует объявить ДВА ключа:тот, который включает дату начала, и тот, который включает дату окончания.

Еще одна проблема дизайна — наличие нескольких столбцов данных.Этот вопрос довольно подробно обсуждается в статье «Временные данные и реляционная модель»:если INFO1 и INFO2 могут изменяться независимо друг от друга, возможно, было бы лучше разложить ваши таблицы так, чтобы они содержали только один атрибут, чтобы избежать «взрывного увеличения количества строк», которое в противном случае могло бы произойти, если бы вам приходилось создавать новую полную строку каждый раз. время, когда изменяется один единственный атрибут в строке.В этом случае ваш проект в том виде, в каком вы его дали, представляет собой нарушение ШЕСТОЙ нормальной формы, как (эта нормальная форма) определена в «Временные данные и реляционная модель».

Answer 2

Нормализация — это концепция реляционной базы данных, она не применима к темпоральным базам данных.Это не значит, что вы не можете хранить временные данные в реляционной базе данных.Вы определенно можете.

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

Answer 3

Вы не указали значение дат.Относятся ли они к (а) периоду, когда заявленный факт был верен в реальной жизни, или (б) к периоду, когда установленный факт был верен в реальной жизни? считается правдой владельцем базы данных?Если бы (б), то я бы никогда так не поступил.Переместите обновленную строку в архивную таблицу/журнал сразу после завершения обновления.Если (а), то следующее утверждение сомнительно:

«факты устарели и больше не должны отображаться в пользовательском интерфейсе»

Если факту больше не «нужно отображаться в пользовательском интерфейсе», то ему больше не нужно и находиться в базе данных.Сохранение таких фактов дает только одно:ухудшить общую работоспособность всех остальных.

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

(PS) Сказать, что ваш дизайн хорош, не означает, что у вас не возникнет никаких проблем.SQL крайне плохо подходит для элегантной обработки такого рода информации.«Временные данные и реляционная модель» — отличное рассмотрение этой темы.Еще одну книгу, книгу Снодграсса, тоже часто хвалят, правда, не я.Это что-то вроде кулинарной книги с рецептами решения этих проблем в SQL, о чем свидетельствует следующий разговор на SO об этой книге:

(Q) "Зачем мне это читать?" (А) «Потому что спусковой крючок, который вы просили, находится на странице 135.»