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

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. Если DATE

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

(В) «Зачем мне это читать?» (A) «Потому что запрошенный вами триггер находится на странице 135».

Answer 3

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

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