Проектирование баз данных для момента времени “снимок” данных?
Вы, вероятно, должны иметь тегов.
Я имею в виду этот пример w3schools: Вставка видео в HTML
Редактировать : Подождите, мой ответ пошел от того, что проголосовали и бесполезно быть лучшим ответом? Как это случилось?
blockquote>
7 ответов
Мы сделали это однажды путем создания отдельных таблиц базы данных, которые содержали данные, которые мы хотели создать снимки, но денормализованный, т.е. каждая запись содержал все данные, требуемые иметь смысл, не ссылки на идентификатор, который может или больше не может существовать. Это также добавило дату к каждой строке.
Затем мы произвели триггеры для определенных вставок или обновлений, которые сделали соединение на всех затронутых таблицах и вставили его в таблицы снимка.
Таким образом, это было бы тривиально для записи чего-то, что восстановило данные пользователей к моменту времени.
Если у Вас есть таблица:
пользователь:
id, firstname, lastname, department_id
отдел:
id, name, departmenthead_id
Ваш снимок пользовательской таблицы мог быть похожим на это:
user_id, user_firstname, user_lastname, department_id, department_name, deparmenthead_id, deparmenthead_firstname, departmenthead_lastname, snapshot_date
и запрос что-то как
INSERT INTO usersnapshot
SELECT user.id AS user_id, user.firstname AS user_firstname, user.lastname AS user_lastname,
department.id AS department_id, department.name AS department_name
departmenthead.id AS departmenthead_id, departmenthead.firstname AS departmenthead_firstname, departmenthead.lastname AS departmenthead_lastname,
GETDATE() AS snapshot_date
FROM user
INNER JOIN department ON user.department_id = department.id
INNER JOIN user departmenthead ON department.departmenthead_id = departmenthead.id
Это гарантирует, что каждая строка в снимке верна в течение того момента вовремя, даже если отдел или начальник отдела изменились тем временем.
SQL Server 2005 (вперед) Enterprise Edition имеет способность создать снимки Базы данных
Наличие снимков и/или журнала аудита является требованием общей базы данных. Для многих приложений составление 'теневых' или контрольных таблиц является легкой и прямой задачей. В то время как резервные копии уровня базы данных и журналы транзакций хорошо иметь, они не система управления версиями.
В основном Вы должны составить теневую таблицу со всем одинаковым столбцы как базовая таблица и затем установить, включает базовую таблицу для размещения копии строки в теневой таблице, когда когда-либо она обновлена или удалена.
Через некоторую логику можно воссоздать то, на что данные были похожи в определенный момент времени. Для простого способа настроить это в Sybase см.: http://www.theeggeadventure.com/wikimedia/index.php/Sybase_Tips#create_.27audit.27_columns
Если необходимо сделать много исторических снимков, то можно сохранить данные в той же таблице. В основном создайте два столбца - добавленный и удаленный столбец. Оборотная сторона для каждого запроса, который необходимо добавить где пункт. Конечно, можно создать представление, которое показывает просто активные записи. Это становится немного более сложным, если у Вас есть нормализованная база данных с несколькими таблицами, все с историей.
Однако это действительно работает. У Вас просто есть 'добавленные' и 'удаленные' столбцы на каждой таблице, и затем Ваш запрос имеет момент времени интереса. Каждый раз, когда данные изменяются, необходимо скопировать текущую строку и отметить ее, как удалено.
Это не легко.
Вы по существу просите Временную Базу данных (Что Christopher Date называет Шестой Нормальной формой, или 6 нФ).
Чтобы быть 6 нФ, схема должна также составить 5 нФ, и, в основном, для каждой данной величины, необходимо присоединить диапазон времени, для которого данная величина в том значении применима. Затем в соединениях, соединение должно включать только строки, которые являются в диапазоне времени, который рассматривают.
Временное моделирование трудно - это - то, к чему 6-я Нормальная форма обращается - и не хорошо поддерживаемая в текущем RDBMSes.
Проблемой является гранулярность. 6-я Нормальная форма (насколько я понимаю) поддерживает временное моделирование путем создания каждого неключа (неключ: т.е. что-либо "на" объекте, который может измениться без объекта, теряющего его идентификационные данные), отдельное отношение. К этому Вы добавляете метку времени или диапазон времени или номер версии. При создании всего, соединение решает проблему гранулярности, но это также означает, запросы будут более сложными и медленнее. Это также требует выяснения всех ключей и неключевых атрибутов; это имеет тенденцию быть большим усилием.
В основном везде у Вас есть отношение ("Тед, владеет акционерным сертификатом GM с идентификатором 789"), Вы добавляете время: "Тед владеет акционерным сертификатом GM с идентификатором 789 теперь" так, чтобы можно было одновременно сказать, "fred владеет акционерным сертификатом GM с идентификатором 789 с 3 февраля 2000 к вчера". Очевидно, эти отношения являются many-many, (Тед может владеть больше чем одним сертификатом теперь, и больше чем один за его время жизни также и fred мог ранее владеть разъемом сертификата, владеет теперь).
Таким образом, у нас есть таблица владельцев, и таблица сертификатов запаса и many-many таблица, которая связывает владельцев и сертификаты идентификатором. К many-many таблице мы добавляем start_date и end_date.
Теперь, предположите что каждое состояние/область/земельные налоги дивиденды на сертификатах запаса, так в целях налогообложения записывать состояние владельца акционерного сертификата резиденции.
То, где владелец находится, может, очевидно, измениться независимо с владением запаса; Тед может жить в Небраске, купить 10 долей, получить дивиденд, что налоги Небраски, перемещение в Неваду, продают 5 акций fred, купите еще 10 долей.
Но для нас, это - Тед, может переместиться в Небраску в некоторое время, купить 10 долей в некоторое время, получить дивиденд в некоторое время, которое налоги Небраски, переместитесь в Neveda в некоторое время, продайте 5 акций fred в некоторое время, купите еще 10 долей в некоторое время.
Нам нужен весь изо что, если мы хотим вычислить то, что налоги Тед должны в Небраске и в Неваде, соединяющейся на диапазонах даты соответствия/наложения в person_stockcertificate и person_address. Адрес человека больше не является непосредственным, это - one-many, потому что это - адрес во время диапазона времени.
Если Тед покупает десять долей, действительно ли мы моделируем событие покупки с единственной датой покупки, или мы добавляем date_bought к каждой доле? Зависит от вопроса, на который нам нужна модель для ответа.
Oracle от версии 9i имеет технологию Ретроспективного кадра, которая находится в Oracle 10 г и 11 г, очень улучшенных, и Вы видите состояние своей базы данных в любой данной точке в истории, если Вы включаете ретроспективный кадр.
Проверьте этот документ: Обзор Ретроспективного кадра
С SQL Server, по крайней мере, можно использовать Полный вход и сохранить журналы транзакций между каждым набором резервных копий.
Затем можно сделать резервное копирование момента времени.
Это - плохое решение.
Что точно хочет Ваш клиент? Это в аналитических целях (т.е. вопросы похожи, сколько заказов мы имели две недели назад)? Поскольку это - точно проблема, которую решает datawarehouse.
Можно использовать журналы, произведенные RDBMS для получения снимков данных. Обычно журналы используются для обеспечения восстановления базы данных. Они могут однако также использоваться, чтобы копировать данные через несколько экземпляров RDBMS или получить снимки данных.
Для получения снимка данных просто примите во внимание все журналы, произведенные перед желаемым моментом вовремя. Вы затем "воспроизводите" те журналы для получения фактической базы данных с восстановленными данными.
То, как получить доступ и "воспроизвести" журналы, зависит от конкретного продукта RDBMS, который Вы используете.
Другая возможность состоит в том, чтобы использовать временные базы данных. Им встроили аспекты времени и позволяют "going-back-in-time". Ищите "Технологию Oracle Flashback", например. http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10795/adfns_fl.htm#ADFNS1008