Обработка временной природы данных — непростая задача. Представьте, что у вас есть простая база данных клиентов, которая показывает, что Джейн Доу живет в Сиднее и работает клерком. Ваш менеджер готовится связаться с Джейн, но он может только догадываться, когда эта информация была получена, не переехала ли Джейн в другой город или не сменила ли работу, как долго она живет в Сиднее и т.д.
Типичная оперативная база данных не учитывает время: она представляет только "текущее" состояние объектов реального мира, хотя на самом деле оно является не текущим, а более или менее устаревшим. При этом неизвестно, когда были получены данные и когда объект фактически находился в таком состоянии.
Немного более продвинутый подход записывает все изменения свойств объекта в журнал истории. Это позволяет отслеживать изменения и предполагать, насколько устарела ваша информация, но не более того. Что, если нам нужно выбрать всех клиентов, которые проживали в Сиднее в 2015 году? Или клиентов, которые когда-либо работали клерком? Большинство баз с журналом истории изменений не дадут ответа.
Мы в DataVera считаем, что потенциал временного измерения бизнес-данных еще предстоит раскрыть. Наша платформа виртуализации данных EKG Provider предоставляет API, который позволяет легко получать состояние данных на каждый момент времени. Любое изменение данных, записываемое в платформу, может сопровождаться отметкой времени, отражающей момент, когда реальные свойства объекта были изменены (или будут изменены). Мы считаем, что это придает данным новое качество, поскольку теперь они могут давать гораздо больше аналитической информации, которую можно монетизировать.
DataVera EKG Provider представляет все данные в соответствии с онтологической моделью. В онтологическом мире время обычно моделируется явно. Если некоторая сущность может иметь различные состояния, каждое состояние представляется в виде отдельного объекта, называемого "временнОй частью". Это означает, что если мы хотим отслеживать историю смены места проживания и места работы наших клиентов, мы должны создавать отдельный объект модели для каждого факта проживания клиента в определенном городе или его занятости на какой-то работе. Это семантически правильно, но довольно неудобно и медленно с точки зрения алгоритмов обработки данных. Простой вопрос типа "кто жил в Сиднее в 2015 году?" становится сложным запросом SPARQL, не очень эффективным на миллионах объектов.
Наш подход реализует темпоральность данных на уровне платформы. Вы можете выполнить простой запрос, например "кто живет в Сиднее?", дополнив его отметкой времени, обозначающей интересующий момент, и получить правильный результат, отражающий прошлое состояние данных. Забудьте о сотнях дополнительных объектов данных для состояний каждого объекта, забудьте о реификации свойств только для того, чтобы отразить их временнУю природу. Работайте с простой структурой данных, которая по-прежнему представляет собой "моментальный снимок" реального мира, в сочетании с возможностью прокручивать ось времени в любом направлении.
Каждая часть данных, каждое значение свойства в EKG Provider аннотируется источником данных (пользователь, внешняя ИТ-система и т. д.), а также временем, когда произошло соответствующее реальное событие. Это повышает доверие к данным и их ценность, открывает путь к более продуманному принятию решений.
