Открытый семинар для студентов в компании CUSTIS (24 апреля 2014 года). Лектор: Максим Зинченко, ведущий разработчик Java/Oracle. Аннотация: На этом семинаре мы рассмотрим, как работают учетно-аналитические системы и системы поддержки принятия решений, в которых необходимы виртуальные перемещения во времени. Мы структурируем знания о проектировании темпоральных систем и необходимости таких хранилищ для бизнеса, рассмотрим самые распространенные проблемы реализации и шаблоны их решений, а также сделаем обзор последних достижений в этой области от гигантов индустрии. Видеозапись семинара: https://vimeo.com/93000420.

1. 24 апреля 2014 года
Темпоральные базы данных:
как построить машину времени
Максим Зинченко
Oracle/Java-разработчик

2. Ему бы только деньги,
деньги, деньги…
Кто я? Что я здесь делаю?
 Окончил МИФИ
 В IT работаю 13 лет
 Программирую 20 лет
QBasic, C++, Pascal, С, Delphi, TSQL,
PL/SQL, Java 1.3, C#, Java 1.7…
 Работаю в CUSTIS 5 лет.
Автоматизация банков
2/ 111

3. За что я люблю CUSTIS
 Зарплата
 Бесплатные плюшки, чай, кофе…
 Корпоративы, пятничные посиделки…
 Расположение офиса
 Можно работать удаленно
 Нормальные рабочие места
3/ 111

4. За что я люблю CUSTIS
♥ Есть у кого поучиться
♥ Свобода творчества
♥ Руководитель – ваш друг
♥ Прозрачность и рефлексия
4/ 111

5. План
 Философия времени
5/ 111

6. План
 Философия времени
 Модели машин времени
6/ 111

7. План
 Философия времени
 Модели машин времени
 Реализация
7/ 111

8. Суть времени
8/ 111

9. Почувствуй время
 Простые определения всегда идут
от ощущений
 Что нужно, чтобы почувствовать время?
9/ 111

10. Роль памяти
 Без памяти невозможно ощутить время
 Память хранит прошлое
 Мы помним события, в которых
не участвовали
 Память хранит и будущее
10/ 111

11. Классическое представление
 Бесконечность
 Детерминированность
 Непрерывность
 Равномерность
 Объективность
11/ 111

12. Альтернативные модели
 Ограниченность (начало и конец времен)
 Недетерминированность (случайности)
 Квантование (минимальная единица)
 Неравномерность
 Субъективность
12/ 111

13. Какая же будет модель у нас?
 Ограниченная по времени
 Недетерминированная (открытая)
 Квантованная
 Равномерная
 Объективная
13/ 111

14. Причины и следствия
 Причины всегда в прошлом
 Асимметрия времени: следствие
не определяет причины
 Меняя причины, можем получить другое
следствие
14/ 111

15. Машина времени
 С сутью времени вроде понятно
 Что такое машина времени?
15/ 111

16. Что умеет машина времени?
1. Наблюдение за прошлым и будущим
2. Изменение прошлого и будущего
3. ???
4. PROFIT!
16/ 111

17. Можно ли ее построить?
 В реальном мире – видимо, нет
 В виртуальном – можно, но сложно
 Зачем же она тогда нужна такая?
17/ 111

18. Зачем нужна машина времени
18/ 111

19. Предпосылки
 Информационный бум
 Новые возможности/потребности
 Слияние виртуального и реального миров
19/ 111

20. Необходимость наблюдений
 Разборки по факту проблем
 Анализ активности в прошлом
 Анализ «что если?»
 Принятие решений на основании будущего
20/ 111

21. Необходимость изменений
 Ошибки в прошлом
 Запаздывание получения информации
 Осуществление действий в точное время
(планирование)
21/ 111

22. Парадоксы
 Изменения в прошлом и будущем рождают
«парадоксы»
 На самом деле это просто коллизии
причин и следствий
 Парадоксы виртуального мира работают
так же, как и в реальном
22/ 111

23. Решения парадоксов
 Все они сводятся к решению «парадокса
дедушки»
 Многочисленные фантасты давно все
написали
23/ 111

24. Решения парадокса дедушки
 Ветвление вселенной
 Эффект бабочки
24/ 111

25. Решения парадокса дедушки
 Слияние линий времени
(эластичность/упругость)
 Принцип запрета
25/ 111

26. Решения парадоксов дедушки
 Замещение
 Довольно сурово, зато просто
26/ 111

27. Что дальше?
 «Парадоксы» можно решать
 Пора приступать к реализации нашего
мира…
27/ 111

28. Терминология
 Для начала введем
несколько терминов …
28/ 111

29. Основные термины
 Период действия
 Линии времени
 Сущности
 Факты
 Агрегаты
29/ 111

30. Периоды действия
 Гранулярность/квантование/единица
 Непрерывные и непересекающиеся
30/ 111

31. Периоды действия
 Гранулярность/квантование/единица
 Непрерывные и непересекающиеся
 Открытость краев
Можно использовать закрытые края как открытые
Вместо 13.03.2014 00:00 - 02.05.2014 00:00
Используем 13.03.2014 00:00 - 02.05.2014 23:59
Нет ли здесь проблемы?
Имеем дырку 02.05.2014 23:59 - 03.05.2014 00:00
Окончание периода
стало как бы открыто
Дырка
в 1 минуту
31/ 111

32. Периоды действия
 Гранулярность/квантование/единица
 Непрерывные и непересекающиеся
 Открытость краев
Можно использовать закрытые края как открытые
Вместо 13.03.2014 00:00 - 02.05.2014 00:00
Используем 13.03.2014 00:00 - 02.05.2014 23:59
Имеем дырку 02.05.2014 23:59 - 03.05.2014 00:00
 Полная определенность на всем времени
Нужны константы для начала и конца времен
32/ 111

33. Линии времени
 Линий (осей) времени может быть
несколько
Дам кредит
Хочу денег
33/ 111

34. Линии времени
 Линий (осей) времени может быть
несколько График погашения:
Янв 100
Фев 100
Мар 100
Апр 100
Май 100
…
Давай
34/ 111

35. Линии времени
 Линий (осей) времени может быть
несколько
100
Январь
35/ 111

36. Линии времени
 Линий (осей) времени может быть
несколько
100
Февраль
36/ 111

37. Линии времени
 Линий (осей) времени может быть
несколько
100
Март
37/ 111

38. Линии времени
 Линий (осей) времени может быть
несколько
200
Апрель
38/ 111

39. Линии времени
 Линий (осей) времени может быть
несколько
График погашения:
…
Мар 100
Апр 200
Май 95
Июнь 95
Июль 95
…
39/ 111

40. Линии времени
 Получаем графики
 То есть одна ось времени у нас в графике
 А вторая – ось реального времени
Янв–Мар:
Янв 100
Фев 100
Мар 100
Апр 100
Май 100
Июнь 100
…
Апр–???:
…
Мар 100
Апр 200
Май 95
Июнь 95
Июль 95
…
40/ 111

41. Линии времени
 Парадокс в будущем здесь мы разрулили
через ветвление
 Можно было бы разрулить через слияние
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Апр 200 Май 95 Июнь 95
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Апр 200
41/ 111

42. Линии времени
 Фантастическое объяснение битемпоральности
Путешественник
во времени
Одно время
Другое время
42/ 111

43. Битемпоральность и ветвление
Реальное время Апрельская ветка
Январь
Февраль
Март
Апрель
Май
Июнь
Янв Фев Мар Апр Май Июнь
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Янв 100 Фев 100 Мар 100 Апр 200 Май 95 Июнь 95
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Янв 100 Фев 100 Мар 100 Апр 200 Май 95 Июнь 95
Время внутри
плана платежей
43/ 111

44. Названия осей времени
 Зависят от области применения
 Обычно одна из осей соответствует
реальному времени
 Системное
 Астрономическое
 Реальное
 Транзакционное
 Эта ось отличается тем, что для нее
значения времени задаются автоматом
44/ 111

45. Названия осей времени
 Прочие оси называют по-разному
 Для обобщения их можно называть:
 Бизнес-ось
 Модельная ось
 Ось валидности
 Здесь больше свободы с указанием
периодов
45/ 111

46. Сущность
 Идентификация (неизменность сути)
 Человек сменил паспорт
 У торта отрезали кусок
 Документ породил документ
 Отделимость
 100 рублей наличными и на счету
 Дырка от бублика
 Протяженность во времени
46/ 111

47. Факт
 Соответствуют понятию Transaction fact
в DWH
 Сущность, у которой отобрали период
 Часто изменения сущностей регистрируют
как факт
47/ 111

48. Агрегат
 Копят результаты фактов в разрезе
измерений
 Искусственная вещь
 Обычно нет ссылок на агрегат
 Появляются и исчезают
48/ 111

49. Темпоральные атрибуты
 Изменяемые/неизменяемые атрибуты
 Темпоральность
 Нетемпоральные можно рассматривать
как действующие бесконечно
49/ 111

50. А где же код наконец?
Когда уже сделаем что-то?
50/ 111

51. Создадим модель…
 Используем наш пример про кредит
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Апр 200 Май 95 Июнь 95
51/ 111

52. Первый шаг
 Имеем факт платежа с такими атрибутами:
 Сумма – темпоральный
 Дата платежа – на бизнес-оси
 Период актуальности – на системной
 Попробуем нарисовать таблицу…
52/ 111

53. Первый шаг
pay_date actual_from actual_to summ
Янв Янв 100
Фев Янв … 100
Март Янв … 100
Апр Янв Март 100
Май Янв Март 100
Июнь Янв Март 100
Апр Апр … 200
Май Апр … 95
Июнь Апр … 95
Янв 100 Фев 100 Мар 100 Апр 100 Май 100 Июнь 100
Апр 200 Май 95 Июнь 95
53/ 111

54. Первый шаг
pay_date actual_from actual_to summ
Янв Янв +∞ 100
Фев Янв +∞ 100
Март Янв +∞ 100
Апр Янв Март 100
Май Янв Март 100
Июнь Янв Март 100
Апр Апр +∞ 200
Май Апр +∞ 95
Июнь Апр +∞ 95
Здесь можно
использовать -∞
54/ 111

55. Второй шаг
 У разных клиентов платежи отдельные
 Появляется сущность «Клиент»
 Клиент должен быть битемпоральным
 Клиент это не факт, а сущность
55/ 111

56. Второй шаг
Ссылка
на клиента
Период действия
на оси платежей
Период
действия на оси
нашего времени
56/88
56/ 111

57. Второй шаг
pay_date client_id actual_from actual_to summ
Янв 1 Янв +∞ 100
Фев 1 Янв +∞ 100
Март 1 Янв +∞ 100
Апр 1 Янв Март 100
Май 1 Янв Март 100
Июнь 1 Янв Март 100
Апр 1 Апр +∞ 200
Май 1 Апр +∞ 95
Июнь 1 Апр +∞ 95
id name actual_from actual_to business_from business_to
1 Клеент -∞ +∞ -∞ +∞
Платежи
Клиенты
Опечатка
57/ 111

58.  Попробуем исправить опечатку
 Мы хотим сохранить любую историю
 Получается, что любое изменение
в Клиентах приведет к порождению новой
записи:
id name actual_from actual_to business_from business_to
1 Клеент -∞
2014-04-
24
17:45:37
-∞ +∞
2 Клиент
2014-04-24
17:45:37 +∞ -∞ +∞
Третий шаг
Поскольку это опечатка
 Кто заметил проблему?
58/ 111

59. Третий шаг
 Попробуем исправить опечатку
 Мы хотим сохранить любую историю
 Получается, что любое изменение
в Клиентах приведет к порождению новой
записи:
id name actual_from actual_to business_from business_to
1 Клеент -∞
2014-04-24
17:45:37
-∞ +∞
2 Клиент
2014-04-24
17:45:37
+∞ -∞ +∞
 Кто заметил проблему?
59/ 111

60. Третий шаг
id name actual_from actual_to business_from business_to
1 Клеент -∞
2014-04-24
17:45:37
-∞ +∞
2 Клиент
2014-04-24
17:45:37
+∞ -∞ +∞
pay_date client_id actual_from actual_to summ
Янв 1 Янв +∞ 100
Фев 1 Янв +∞ 100
Март 1 Янв +∞ 100
Апр 1 Янв Март 100
Май 1 Янв Март 100
Июнь 1 Янв Март 100
Апр 1 Апр +∞ 200
Май 1 Апр +∞ 95
Июнь 1 Апр +∞ 95
Клиенты
Платежи
Мы не можем
сослаться
на все версии
клиента
60/ 111

61. Третий шаг
Что-то здесь надо
менять
61/ 111

62. Третий шаг
name
Темпоральные данные
переезжают
Атрибуты периодов
тоже переезжают
Версии
клиентов
62/ 111

63. Третий шаг
name
Атрибуты периодов
тоже переезжают
Можно оставить здесь
нетемпоральные данные
Версии
клиентов
63/ 111

64. Третий шаг
client_id name actual_from actual_to business_from business_to
1 Клеент -∞
2014-04-24
17:45:37
-∞ +∞
1 Клиент
2014-04-24
17:45:37
+∞ -∞ +∞
pay_date client_id actual_from actual_to summ
Янв 1 Янв +∞ 100
Фев 1 Янв +∞ 100
Март 1 Янв +∞ 100
Апр 1 Янв Март 100
Май 1 Янв Март 100
Июнь 1 Янв Март 100
Апр 1 Апр +∞ 200
Май 1 Апр +∞ 95
Июнь 1 Апр +∞ 95
Анкеты/верcии клиентов
Платежи
id
1
Клиенты
64/ 111

65. Лишняя таблица
 Какая-то странная таблица Клиентов?
 Может, удалить ее, ведь в ней нет
полезной информации?
65/ 111

66. Лишняя таблица
Это можно сделать, если:
 Нет ссылок на клиентов
 Вы не считаете важными FK
 Нет нужды рассматривать клиента как единое
целое
 Вы готовы делать ссылки не на клиента,
а на версию клиента
66/ 111

67. Ссылки на версию/анкету
 Немного проще запросы
 Сложнее изменения в датах
То есть больше подходит для OLAP
67/ 111

68. Альтернативы подходу версий
 Подход «сущность + версии» –
не единственный
 Одна из популярных альтернатив: 6НФ
 Посмотрим, что это такое…
68/ 111

69. Шестая НФ
 Пусть у клиента два темпоральных атрибута:
имя и адрес
name address
Иванов Гагарина, 34
Иванов Ленина, 41
Иванов Мира, 12
Адрес меняется, имя остается
69/ 111

70. Шестая НФ
Имя клиента
в отдельной
таблице
Адрес тоже
в отдельной
таблице
Как и с версиями,
здесь можно
что-то оставить
СРАВНИТЕ
70/ 111

71. EAV модель
 Таблицы атрибутов очень похожи
 Можно сделать вот так
71/ 111

72. Как еще можно…
 От EAV до NoSQL один шаг
 Можно смешать подходы по-разному
 Часто акцентируются на текущих значениях
72/ 111

73. Но вернемся обратно
 Все альтернативы рассмотреть нереально
 Вариант с версиями поддерживается
лучше современными СУБД
 Поэтому вернемся к нему…
73/ 111

74. Получение данных
Как же получить данные?
74/ 111

75. Получение данных
 Нужно фиксировать даты по всем осям
 Дату системного времени обычно ставят
в +∞ или текущую
 Пользователю остается выбрать бизнес-
дату (или бизнес-даты)
75/ 111

76. Получение данных
Эта часть –
как у обычных запросов
Задаем бизнес-дату
Задаем системную
дату
76/ 111

77. Контроль ссылок
 Не все сущности полностью определены
 Нужен контроль допустимости ссылки
 Рассмотрим на примере системного
времени…
77/ 111

78. Системное время
Беспроблемная ссылка
78/ 111

79. Системное время
Платеж
до создания
клиента
Клиента удалили,
а платеж продолжает жить
79/ 111

80. Системное время
Допустимая ссылка, но могут
быть проблемы
Допустимая ссылка,
но могут быть проблемы
80/ 111

81. Контроль уникальности
 Периоды не должны пересекаться
для одной сущности
 Это условие не так легко понять
при мультитемпоральной модели
81/ 111

82. Внесение изменений
 Ветвление
 У новых версий actual_from ставим в текущий
момент
 Окончание обычно неизвестно
 Укорачиваем при необходимости предыдущую
запись
82/ 111

83. Внесение изменений
 Ветвление
 У новых версий actual_from ставим в текущий
момент
 Окончание обычно неизвестно
 Укорачиваем при необходимости предыдущую
запись
83/ 111

84. Внесение изменений
 Изменения затрагивают бизнес-ось?
 Здесь можно произвольно задавать период
 Поэтому изменения могут вноситься
в несколько периодов
84/ 111

85. Внесение изменений
 Изменения затрагивают бизнес-ось?
 Здесь можно произвольно задавать период
 Поэтому изменения могут вноситься
в несколько периодов
85/ 111

86. Внесение изменений
 Изменения затрагивают бизнес-ось?
 Здесь можно произвольно задавать период
 Поэтому изменения могут вноситься
в несколько периодов
 Иногда они могут даже поглощаться
86/ 111

87. Внесение изменений
 Изменения затрагивают бизнес-ось?
 Здесь можно произвольно задавать период
 Поэтому изменения могут вноситься
в несколько периодов
 Иногда они могут даже поглощаться
87/ 111

88. Внесение изменений
 Эффект бабочки
 Причинно-следственные связи
 Изменение причины часто приводит
к изменению следствия
Меняет фамилию
на Петров
88/ 111

89. Внесение изменений
 Эффект бабочки
 Причинно-следственные связи
 Изменение причины часто приводит
к изменению следствия
Меняет фамилию
на Петров
89/ 111

90. Внесение изменений
 Эффект бабочки
 Причинно-следственные связи
 Изменение причины часто приводит
к изменению следствия
Меняет фамилию
на Петров
90/ 111

91. Агрегаты
 Храним общую сумму платежей по годам:
pay_year actual_from actual_to value
2013 -∞ +∞ 10000
2014 -∞ 01.04.2014 20100
2014 01.04.2014 +∞ 20200
Изменение суммы
платежа
Измерение: год
(бизнес-ось)
Период действия
(системный)
91/ 111

92. Агрегаты
 Агрегат часто неявно связан с многими
фактами и сущностями
 Это затрудняет реализацию эффекта
бабочки
92/ 111

93. Попытки сделать стандарт
93/ 111

94. SQL-2011
 Родился в декабре 2011
 Седьмая версия SQL
 Платный сыр
94/ 111

95. SQL-2011. Бизнес-ось
 Создаем табличку
Поля периода
создаем вручную
Говорим, что эти поля
для нашей осиНазвание оси
95/ 111

96. SQL-2011. Системная ось
 Добавляем системное время:
Эти поля – это начало
и конец действия
96/ 111

97. SQL-2011. Системная ось
 Добавляем системное время:
Поля принадлежат системной оси
97/ 111

98. SQL-2011. Системная ось
 Добавляем системное время:
Название
фиксировано
98/ 111

99. SQL-2011. Системная ось
 Добавляем системное время:
Можно сделать PK или UNIQUE
99/ 111

100. SQL-2011. Системная ось
 Добавляем системное время:
Нужна такая специальная фраза
100/ 111

101. SQL-2011. Факты
 Как же сделать факт?
Одинаковые даты
Темпоральная ссылка
К сожалению, скорее
всего, так работать
не будет!
101/ 111

102. SQL-2011. Запросы
 На заданные бизнес и системную дату:
Условие пишем
отдельно для каждой
таблички
Предусмотрена фильтрация только одной
оси, вторую приходится самим
102/ 111

103. SQL-2011. Изменения
 По бизнес-оси нужно задавать время
 Системное время ставится автоматом
103/ 111

104. SQL-2011. Проблемы
 Многословно
 Включительные границы
 Нет группировки по периоду
 Трудно работать с 2+ количеством осей
 Нет поддержки нестандартных типов
периодов
 Нет поддержки хранимых агрегатов
104/ 111

105. Попытки реализовать стандарт
105/ 111

106. IBM DB2 10+
 Создание таблиц, в целом, такое же
 Для SYSTEM_TIME нужно вручную
создавать табличку истории и привязывать
 Добавили конструкцию
106/ 111

107. Oracle DBMS 12+
 Много мелких отличий от стандарта
 Задание даты для системной оси:
 Для системной оси ведутся специальные
системные поля с данными об scn
и операции
 Требование date_to>date_from
107/ 111

108. Что еще?
 Получение среза связанных данных
на конкретный момент
 Агрегаты
 Альтернативы анкетам
 Транзакционное/модельное время
 Ограничения уникальности
 Логическое удаление
108/ 111

109. Спасибо!
Вопросы?
109/111

110. Спасибо!
Вопросы?
Максим Зинченко
zinchenko@custis.ru
110/111