Лучшее представление реляционных баз данных иерархий с ограничением по времени - PullRequest
Новая
       25

Лучшее представление реляционных баз данных иерархий с ограничением по времени

5 голосов
/ 19 апреля 2009

Что, по мнению каждого, является лучшим представлением иерархии с временными ограничениями в SQL?

Что я имею в виду под этим:
- На любую дату у вас есть нормальная древовидная иерархия
- Эта иерархия может меняться изо дня в день
- У каждого ребенка все еще есть только один родитель на любую дату

День 1 ... 

Business
 |
 |-Joe
 |  |-Happy
 |  |-Sneezy
 |  |-Doc(*)
 |
 |-Moe
    |-Bashfull
    |-Sleepy

День 2 ... 

Business
 |
 |-Joe
 |  |-Happy
 |  |-Sneezy
 |
 |-Moe
    |-Doc(*)
    |-Bashfull
    |-Sleepy

В любое время ребенок может впервые присоединиться к иерархии или полностью покинуть иерархию. (Например, новые работники и пенсионеры.)

Основные соображения:

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

Я знаю, как я это делаю в настоящее время, но я заинтригован тем, как другие люди могут это делать:)

EDIT

Я наивно предполагал несколько соображений, поэтому буду более явным ...

  • Каждая «команда» или «человек» будет иметь уникальный идентификатор в таблице измерений в других местах
  • В других таблицах фактов будут использоваться эти идентификаторы (например, для хранения показателей производительности)
  • Структура должна облегчать историческую отчетность по диапазонам дат
  • Использование ETL или триггеров для поддержки альтернативных структур. Опция

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

Ответы [ 4 ]

8 голосов
/ 19 апреля 2009

Здесь есть несколько разных релевантных книг: один набор предназначен для «временных баз данных», а другой - для «иерархических структур в РСУБД».

Сложные части вашего вопроса, как мне кажется, таковы:

  • Просмотр всей иерархии в диапазоне дат

  • Отчетность по целым поддеревьям за диапазон дат

Другие элементы, если не прямые, то управляемы с использованием методов, изложенных в книгах, и в соответствии с рекомендациями, приведенными в других ответах. Часть проблемы заключается в понимании того, что означают эти два пункта. В каком-то смысле они «одинаковы»; «вся иерархия» - это особый случай «целых поддеревьев». Но более глубокий вопрос заключается в том, «как вы хотите продемонстрировать - визуализировать, представить - изменения в иерархии с течением времени?». Вы хотите сравнить состояния в начале и в конце, или вы тоже хотите увидеть промежуточные изменения? Как вы хотите представлять движения человека в иерархии?

Больше вопросов, чем ответов - но я надеюсь, что указатели помогут.

0 голосов
/ 19 апреля 2009 
table item(id, ...)

table item_link(parent_item, child_item, from_date, until_date)

Ссылки будут хранить представление дерева в течение определенного времени

Эта структура представляет собой сеть вместо простой иерархии, но она поддерживает перемещение объектов в иерархии, но также оглядывается назад во времени. Некоторые вещи необходимо проверить в логике приложения - запретить одновременное связывание joe в разных местах иерархии.

Отчетность относительно проста с подключением по предыдущему пункту (в оракуле)

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

0 голосов
/ 19 апреля 2009

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

1) Предполагая, что сегодняшняя иерархия является наиболее важной. Я бы сохранил сегодняшнюю иерархию с обычным столбцом ParentId в каждой записи. Для предыдущих версий иерархии у меня была бы таблица истории 

ItemId, ParentId, ValidFromDate, ValidToDate

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

2) Если какая-либо / все иерархии имеют одинаковую важность, я бы сохранил иерархию базовой линии, а затем реализовал таблицу транзакций иерархии. 

TransactionId, ItemId, Action (Move/Delete/Add), DateTime, OldParentId, NewParentId
0 голосов
/ 19 апреля 2009

Здесь может работать пара плоских столов. Для каждой строки нам нужны столбцы ID, Name, ParentID и InactivationDatetime (по умолчанию null). Установите дату и время для старого Документа, принадлежащего Джо, указывая, что эта запись больше не действительна, и переместите ее в архивную таблицу (для чистоты), а затем создайте новую строку (близкую копию исходной строки) для нового Документа с идентификатором Мо в качестве ParentID. Недостаток этого подхода заключается в том, что перемещаемое лицо должно получить новый идентификатор, что может быть неудобно.

...