литература по моделированию исторических данных, методы и приемы

В прошлом году мы запустили http://tweetMp.org.au — сайт, посвященный австралийской политике и Twitter.

В конце прошлого года нашу политическую схему нужно было скорректировать, потому что некоторые политики ушли на пенсию, а на ее место пришли новые политики.

Изменение нашей базы данных требовало ручного изменения (SQL), поэтому я рассматривал возможность внедрения CMS для наших администраторов, чтобы вносить эти изменения в будущем.

Есть также много других сайтов, посвященных правительству/политике Австралии, которые управляют своими собственными данными о политиках.

Я хотел бы придумать централизованный способ сделать это.

Поразмыслив над этим некоторое время, возможно, лучший подход — не моделировать текущее представление данных политика и то, как они соотносятся с политической системой, а вместо этого моделировать транзакции. Таким образом, текущее представление является проекцией всех транзакций/изменений, которые произошли в прошлом.

Используя этот подход, другие сайты могут «подписаться» на изменения (а-ля pubsubhub), отправить изменения и просто интегрировать эти элементы изменений в свои схемы.

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

Я заметил, что некоторые вещи работают таким образом — контроль версий исходного кода, банковские записи, система очков stackoverflow и многие другие примеры.

Конечно, непосредственные проблемы и проблемы проектирования с этим подходом включают

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

Есть ли какая-нибудь заметная литература по этому вопросу, которую кто-нибудь мог бы порекомендовать? Кроме того, какие-либо шаблоны или методы моделирования данных, подобные этому, могут быть полезны?

Любая помощь приветствуется.

-CV


database datamodel data-modeling websub
person CVertex    schedule 16.01.2010    source источник
comment
Методы отслеживания изменений в архитектуре хранилища данных имеют хорошие методы (медленно меняющиеся измерения), которые могут фиксировать подобные вещи. Хорошая вещь в этом заключается в том, что по большей части ваши основные базы данных приложения остаются в покое, недостатком является то, что внесение ретроактивных изменений более сложно, и создание хранилища данных, очевидно, может потребовать много работы. Если людей не устраивает наличие текущей истории в будущем, и они хотят задним числом добавить историю с помощью ввода некоторых данных или часто должны вносить исправления в историю, тогда вам необходимо создать инструменты для вставки этой информации.   -  person AaronLS    schedule 26.05.2012

Ответы (1)


arrow_upward
2
arrow_downward

Это довольно распространенная проблема в моделировании данных. В основном это сводится к следующему:

Интересно ли вам представление сейчас, представление в определенный момент времени или и то, и другое?

Например, если у вас есть служба, которая моделирует подписки, вам необходимо знать:

  • Какие услуги были у кого-либо в определенный момент времени: это необходимо, чтобы определить, сколько взимать плату, просмотреть историю учетной записи и т. д.; и
  • Какие услуги у кого-то есть сейчас: к чему они могут получить доступ на веб-сайте?

Отправной точкой для такого рода проблем является наличие таблицы истории, например:

  • История обслуживания: id, userid, serviceid, start_date, end_date

Соедините вместе истории обслуживания для пользователя, и вы получите их историю. Итак, как вы моделируете то, что у них есть сейчас? Самый простой (и наиболее денормализованный вид) — сказать, что последняя запись или запись с датой окончания NULL или с настоящей или будущей датой окончания — это то, что у них есть сейчас.

Как вы можете себе представить, это может привести к некоторому корявому SQL, поэтому он выборочно деномрализован, поэтому у вас есть таблица Services и другая таблица для истории. Каждый раз, когда Службы изменяются, создается или обновляется запись истории. Такой подход превращает таблицу истории в нечто большее, чем таблицу аудита (еще один термин, о котором часто говорят).

Это аналог вашей проблемы. Ты должен знать:

  • Кто является действующим депутатом от каждого места в Палате представителей;
  • Кто является текущим сенатором для каждого места;
  • Кто является текущим министром каждого департамента;
  • Кто премьер-министр.

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

Итак, 20 августа 2003 года Питер Костелло сделал пресс-релиз, который вам необходимо знать, что в это время он был:

  • Член для Хиггинса;
  • Казначей; и
  • Заместитель премьер-министра.

потому что предположительно кому-то может быть интересно найти все пресс-релизы Питера Костелло или казначея, что приведет к одному и тому же пресс-релизу, но его будет невозможно отследить без истории.

Кроме того, вам может понадобиться знать, какие места находятся в каких штатах, возможно, географические границы и так далее.

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

person cletus    schedule 16.01.2010