Как заставить процессы уничтожения агрегаций документов (aggregate record) работать в системах структурированных данных? Ответ на данный вопрос, судя по всему, является загадкой даже для очень дальновидных специалистов-практиков.
По моему опыту, типичная причина концептуальных проблем в данном случае заключается в том, что люди, пытаясь справиться с поставленной задачей, инстинктивно думают о базе данных.
Это упрощенное представление: У нас есть хранилище данных (контейнер для документов), и мы смотрим на него и думаем, что оно организовано в виде таблиц, в таблицах отражены транзакции, а сведения о транзакциях называются документами - поэтому мы хотим на них посмотреть! (На самом деле, не хотим!)
Использовать подобную логику – всё равно что подойти к куче блоков конструктора Лего и попытаться понять, что же ранее было построено из этих элементов. Это может быть возможно в очень простых случаях, когда база данных вообще не была нормализована, - однако в большинстве случаев уровень уверенности будет очень низким, а вероятность возникновения непредвиденных последствий, наоборот, будет очень высокой.
Более точная аналогия заключается в том, что это похоже на попытку провести экспертизу ценности текстового документа в формате Word, просматривая хранящиеся на жёстком диске биты - единицы и нули. Все становится проще, если Вы используете для этой цели приложение Word.
Чтобы понять, что такое уровень транзакций, нам следует пойти и взглянуть на само деловое приложение и разобраться с тем, как это деловое приложение порождает транзакции. Обычно это достаточно тривиальное дело, когда речь идёт об ориентированных на пользователя приложениях.
Фактически, есть два способа решить эту задачу: или посидеть в течение пяти минут с кем-то, кто использует приложение, и попросить этого коллегу пошагово показать, что он там делает, - или пойти и взглянуть на интерфейс приложения, и поискать там, что именно оно позволяет Вам создавать.
Вам следует сосредоточить своё внимание на существительных.
Приложения разрабатываются для фиксации и обновления состояния вещей — «состояние» (state) просто означает определенные характеристики вещи в определенный момент времени.
«Вещи» почти всегда являются именами существительными – это может быть физическое лицо, клиент, актив, продукт, дело, заказ, контракт и т.д.
Что делает управление документами в системах структурированных данных непонятным и запутанным для специалистов по управлению документами, так это то, что обычно мы предпочли бы иметь одну единственную, содержащую всё «запись», которой мы могли бы управлять вплоть до уничтожения - а если мы не уничтожим всё и вся, то у нас останется чувство, словно мы не сделали того, что от нас ожидалось.
Создающие базы данных специалисты считают такой подход расточительным и неэффективным, поэтому обычно вы видите в базах данных набор связей типа «один ко многим» между существительными, которые представляют человека, место или вещь, и существительными, которые представляют связанные с ними действия (транзакции).
Мой комментарий: Карл Мелроуз пытается здесь объяснить, что в базах данных одни и те же компоненты могут использоваться для «сборки» не одного документа, а многих – и, соответственно, такие компоненты нельзя удалять, пока продолжает храниться хотя бы один документ, для сборки которого они нужны. По аналогии с Лего, при уничтожении документа можно спокойно уничтожить только те блоки и связи, что являются для этого документа уникальными.
Здесь интересно отметить, что если об этом рассуждать с точки зрения классификационных схем, то можно было бы сказать, что речь идёт о структуре «Субъект : Действие : Транзакция» - при этом сведения о действии обычно фиксируются в виде типа транзакции.
Простым примером служат системы менеджмента активов. Скорее всего, у нас будет актив (один), а также набор связанных с активом случаев их использования (много) разных типов (соответствующих разным видам деятельности). Актив (один) связан со многими случаями использования – транзакциями.
Ещё одним примером являются системы «обслуживания клиентов». Клиент (один) связан со многими продажами – транзакциями.
То существительное, которого «много», скорее всего будет нашими «транзакциями».
В какой-то момент всякое существительное, которое «одно», также было создано - и это тоже транзакция, которую в какой-то момент нужно будет удалить.
Именно в этих отношениях «один ко многим» большинство коллег [специалистов по управлению документами – Н.Х.] застревает, когда задумывается об уничтожении информации и документов в базах данных.
Нам нужно осознать, что для уничтожения транзакции нам необходимо избегать уничтожения любых многократно используемых данных и уничтожать только те данные, которые уникальны для данной транзакции. Если мы удалим уникальные данные, связанные с транзакцией, то уничтожим возможность представления транзакции с помощью тех данных, которые остались, - поэтому тем самым мы уничтожили эту транзакцию. Звучит это сложно, но, как правило, на деле это не так - до тех пор, пока вы избегаете собственно базы данных, как чумы, и взаимодействуете с приложением.
Разработчики приложений обычно не осознают потребность в проведении авторизованного уничтожения, и приложения, соответственно, этого должным образом не поддерживают, - однако функция «удаления» в приложениях обычно имеется, даже если она недоступна обычным пользователям. Если приложение спроектировано хорошо, то функция удаления будет включать в себя логику, защищающую целостность базы данных, на которую опирается приложение, а также ограничивающую круг удаляемых элементов только уникальными для соответствующей транзакции данными (а не всеми элементами, от которых зависит запись о транзакции).
Действительно, при этом остаётся решить проблему уничтожения с такими сущностями, как «физическое лицо» и «адрес» — и с некоторыми другими существительными / сущностями, от которых зависят транзакции, но это небольшая концептуальная проблема, решение которой требует лишь небольшой гибкости мышления. Если мы уничтожили наши транзакции и при этом остались сведения о людях и адресах без привязанных к ним транзакций, и эти сведения используются только для поддержки данных транзакций (т.е. в их отношении нет собственных требований к срокам хранения), то об этом легко собрать отчётность и уничтожить эти сведения в качестве вторичного действия после проведения процесса уничтожения на уровне транзакций.
Ситуация усложняется, когда имеются приложения, использующие эти данные на последующих этапах обработки информации.
Вот для чего нужны сведения о происхождения и перечни видов документов, информации с указанием сроков хранения и действий по их истечении.
Предполагается, что в перечнях указаны сроки, в течение которого нам нужны соответствующие данные, - в том числе для любого последующего использования на дальнейших этапах обработки. Хорошие перечни должны принимать во внимание все виды использования в деловой деятельности, включая последующее и повторное использование. Может быть несколько затруднительно отслеживать всё это, если информация и данные копируются, но это можно сделать.
Сведения о происхождении (lineage) также полезны: они говорят нам, откуда взялись наши данные — это происхождение (provenance) на уровне данных. Если у нас есть сведения о происхождении, то мы знаем, откуда взялись данные и куда они идут. Отсутствие таких сведений может довольно быстро, лет через пять-десять, обернуться масштабными проблемами, особенно если речь идёт о хранилище данных (data warehouse) или, тем более, об озере данных.
Если же говорить серьёзно, то любая мысль о невозможности выполнения процесса уничтожения данных в базах данных просто неверна. Нам лишь нужно убедиться, что мы рассматриваем вопрос на адекватном уровне абстракции. Представление о базах данных [на уровне отдельных полей данных и записей в базе данных – Н.Х.] сродни попытке проведения экспертизы текстового документа в формате Word посредством просмотра потока составляющих его битов на жёстком диске: мы можем добиться куда большего, используя соответствующее программное приложение (Word).
Карл Мелроуз (Karl Melrose)
Источник: блог Meta-IRM
https://metairm.substack.com/p/how-to-make-aggregate-record-destruction
Комментариев нет:
Отправить комментарий