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

Question

Я создаю базу данных для хранения большого количества событий. Их будет много, и каждый из них будет связанным временем, точным со вторым. В качестве примера можно привести примерно следующее:

Event 
----- 
Timestamp 
ActionType (FK) 
Source (FK) 
Target (FK) 

Действия, источники и цели все в 6NF. Я бы хотел, чтобы таблица Event была нормализована, но все подходы, о которых я мог думать, имеют проблемы. Чтобы быть в курсе моих ожиданий относительно данных, подавляющее большинство (99,9%) событий будет уникальным только с четырьмя четырьмя полями (поэтому я могу использовать всю строку как ПК), но некоторые исключения не могут быть проигнорированы ,

1. Используйте суррогатный ключ: Если я использую четыре-байтовое целое это возможно, но это, кажется, как только накачивание таблицу без причины. Кроме того, я обеспокоен использованием базы данных в течение длительного периода времени и исчерпанием ключевого пространства.

2. Добавить граф столбец События: Поскольку я ожидаю небольших отсчетов я мог бы использовать меньший тип данные, и это будет иметь меньшее влияние на размере базы данных, но это потребовало бы upserts или объединения данных вне базы данных перед вставкой , Любой из тех, кто хотел бы добавить сложность и влияние на мой выбор программного обеспечения баз данных (я думал идти с Postgres, что делает upserts, но не с удовольствием.)

3. Перерыв События на небольшие группы: Например, все события в одна и та же секунда может быть частью Bundle, которая может иметь суррогатный ключ для группы и другой для каждого события внутри него. Это добавляет еще один уровень абстракции и размера в базу данных. Было бы неплохо, если бы в противном случае повторяющиеся события стали обычным явлением, но в противном случае это кажется излишним.

Хотя все это выполнимо, они кажутся плохими для моих данных. Я думал о том, что просто делал типичную снежинку и не применял ограничение уникальности в главной таблице Event, но после прочтения ответов PerformanceDBA, таких как this one, я подумал, что, возможно, был лучший способ.

Итак, Какой правильный способ сохранить данные временного ряда с небольшим количеством повторяющихся событий нормализован?

Редактировать: Разъяснение - источники данных - это журналы, в основном плоские файлы, но некоторые в различных базах данных. Одна из целей этой базы данных - объединить их. Ни один из источников не имеет более точное разрешение по времени, чем второе. Данные будут использоваться для таких вопросов, как «Сколько разных источников было выполнено действие по целевому значению по интервалу?» где Интервал не будет меньше часа.

Answer 1

Простейших ответов кажется

• магазина метка время с большей точностью, или
• магазина метка время на второй и повторите попытку (с чуть позже метками времени), если INSERT терпит неудачу из-за дубликатом ключа ,

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

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

Добавление «count» colummn имеет смысл, если имеет смысл подсчитывать вещи; иначе это не так. Посмотрите на эти два примера.

Timestamp   ActionType Source Target 
-- 
2013-02-02 08:00:01 Wibble  SysA SysB 
2013-02-02 08:00:02 Wibble  SysA SysB 

Timestamp   ActionType Source Target Count 
-- 
2013-02-02 08:00:01 Wibble  SysA SysB 2 

Какая разница в значении здесь? Значение «Временная метка» особенно важно. Нормализация основана на семантике; то, что вам нужно сделать, зависит от того, что данные означает, а не на то, что названы столбцами.

Разрушение событий на небольшие группы может иметь смысл (например, добавление столбца «count» может иметь смысл), если группы событий имеют смысл в вашей системе.