Доклад Николая Соколовского на Analyst Days-7. 13-14 октября 2017. Минск www.analystdays.com

1. Реверс-инжиниринг. Восстанавливаем структуру данных
Николай Соколовский, Станислав Рождественский

2. Dev1: …у нас есть исходный код, посмотрим там
Dev2: [мрачно] в коде лес чудес

3. Когда чаще всего надо реверсить структуру
данных?
1. Миграции данных
A. Из старой версии в новую
B. Из одного продукта в другой (замена
продукта)
2. Интеграции с другими приложениями
3. Поддержка приложения
4. Обновление приложения (новые фичи)
5. Переделка приложения (например смена
технологии)

4. Общие принципы
1. Все лгут (даже код, даже база).
2. Результат (форма, объем, детальность)
должен отвечать цели
3. Все пишется AsIs
4. Документирование – это процесс

5. Что можно использовать как источники
информации?
Технические:
1. База данных + приложение
2. Документация по проекту (в первую очередь системная)
3. Исходный код (code first)
4. Интервью с техническими stakeholders
Бизнес:
1. Нормативная документация
2. Интервью с бизнес Stakeholders
Здравый смысл

6. Как это сделать?
1. В базе все очень хорошо и есть доки
A. При необходимости дополняем/проверяем
документацию скриптами
B. генерация схемы (например Diagram MSSQL
Managment Studio)
C. пачка встреч для верификации, что вы
правы
2. В базе все плохо, источников почти что нет
A. исследование процессов
B. screen mapping + профайлер
C. исследование баз
D. ручное восстановление структуры
E. ручная схема и описание

7. Как найти скрытую логику?
1. Для целых значений:
A. Есть ли негативные, нули, положительные
B. Диапазон чисел
C. не нарушают ли они «смысл»
2. Для дробных значений:
A. Действительно ли там дроби?
B. Сколько знаков после запятой значимо?
C. В какие моменты происходит округление?
3. Даты и время. Какой формат хранения?
4. Для всех связанных таблиц. Есть ли «висячие» строки
5. Действительно ли эта таблица/поле/значение
используется сейчас?

8. Хранение наследования
Как выглядит нормализованное хранение
1. Для каждого уровня наследования своя
таблица
2. Наследники не хранят атрибуты родителя, но
хранят его Id
3. Записей в родительских таблицах столько же
сколько по сумме во всех отнаследованых от
него на всю глубину
Как выглядит не нормализованное хранение
1. Одна таблица с 100+ колонок
2. Колонки родителя всегда заполнены,
колонки наследника null все, если наследник
не задан

9. Как узнать требования к производительности,
консистентности, доступности?
1. Есть ли сочетания разных типов БД (RDB, NoSQL etc)
2. Есть ли распределенные базы
3. Есть ли зеркала данных
4. Как организовано бэкапирование и логирование

10. Как выявить риски интеграции данных?
1. Кто еще пишет в нашу базу и куда?
2. Все ли поля он передает, есть ли «закостыленные»
значения?
3. Куда мы отдаем данные?
4. Использует ли продовская БД или зеркала/поднятые
бэкапы. Каковые лаги по времени?

11. Так исторически сложилось….

12. Не нормализованные таблицы
Как выглядят
1. В столбцах дублируются атрибуты (reviewer1, reviewer2)
2. После Distinct + order by в строках есть такие же, или почти
такие же значения (СПб, СПБ, Питер, Питер. , Санкт-Петербург)
3. Много полей, которые пусты для бОльшей части записей
Что можно сделать
1. Если надо – запланировать рефакторинг
2. Нормализовать на уровне логической модели (с указанием
маппинга на реальные таблицы)

13. Божественный классификатор
Как это выглядит
1. В базе нет справочников
2. Есть странная таблица(ы) с именем вида List, Reference,
Dictionary.
3. Данные в этих таблицах не однородны и не содержат
признака типа записи.
Что можно сделать:
1. Для маппинга составлять справочники выполняя group by в
ссылающейся таблице + join на справочник
2. В конце - проверка скриптом не распределенных значений
Id Value
1 Палата 101
… …
154 F20.0
Шизофрения
… ….
1140 Выписан
… …
2240 Стол №3
… …

14. Некорректное удаление данных
Как выглядят
1. Одна таблица имеет статус/флаг
deleted/Archived другая нет. При этом мы
имеем дело с композицией сущностей
2. Left join к ссылающейся с отбором всех
удаленных вернет таблицу вида
Что можно сделать:
1. Обязательно выяснить причину
2. Учесть при использовании данных
MainTable->Id ReferencedTable-Id
Null 1
Null 2

15. Мертвые справочники и позиции в них
Как это выглядит
Join от справочника на все использующие таблицы
возвращает null
Что можно сделать:
1. Выяснить историю справочника (есть ли исторические
данные, используется ли в других системах)
2. Проверить что действительно не используется в
существующем коде (у разработчиков)
3. Проверить что не используется более в домене
(спросить у бизнеса)

16. Магические числа
Как выглядят
1. В поле, которое по сути является справочником,
лежат числа.
2. Самого справочника нет как отдельной таблицы
Что можно сделать:
1. Восстанавливать значения через код
2. Либо через скриншоты / тестовые прогоны, следя за
тем как меняются значения
3. Если надо – запланировать рефакторинг

17. Странные имена
Как выглядят
1. Транскрибированные (oborudovanije)
2. Без семантики (Field1)
3. Обманывающие (user = patient)
4. В базе 4 приложения, и нет схем
Что можно сделать:
1. Перепроверить семантику и ведение (разработчики +
бизнес)
2. Если надо – запланировать рефакторинг

18. Нет ключей (в т.ч. первичных)
Как это выглядит
Список keys пуст
Что можно сделать:
1. Синтаксический анализ (id, FieldId, имя поля
совпадает с именем имеющейся таблицы) + опрос
разработчиков
2. Анализ view, stored procedure
3. Профайлер

19. Мусорные данные
Как выглядит
Select field_name, count(field_name) from…. group by field_name
Возвращает что-то не укладывающиеся в семантику хранимых данных. Например:
1. Много пустых строк для текстовых полей
2. Не существующий Id в FK: -1, 0
3. Много несуразных дат (01/01/1900)
4. Все забито одними и тем же данными.
Например, время всегда – полночь
Что можно сделать:
1. Подтвердить расхождения с семантикой
2. Выяснить почему система пишет такие данные

20. Когда часы врут
1. Не верный часовой пояс сервера + хранение информации без указания часового пояса
2. Не используется при реальной необходимости
3. Ложное время
Как выглядит
1. Вам об этом сказали
2. Повторяющиеся значения
Что можно сделать:
1. Зависит от цели, в целом ничего

21. Суммы не бьются
1. Производные статусы
2. Итоговые суммы
Как выглядит
1. Обычное поле
2. Явные указания в логике / коде
3. Однотипные поля в основной и дочерних сущностях
Что можно сделать:
1. Перепроверить что вычисления проводились верно на всем
наборе данных

22. Спасибо за внимание
Соколовский Николай
Email:
sokolovskynik@gmail.com
Facebook:
https://www.facebook.com/sokolovskynik
Станислав Рождественский
Email:
Stanislav.Rozhdestvenskiy@dataart.com
LinkedIn:
https://www.linkedin.com/in/sirojdestvensky